Foren-Tage 2017 - Themen-"Wünsch-Dir-was"

[Benedikt Magnus]

Zitat von Mavarik:

wow... Das ist aber eher etwas für 2 Tage und nicht für einen Vortrag von einer Stunde... bzw. kommt darauf an was du als letzte Jahre bezeichnest...

Seit Delphi 7? oder seit XE6 (das geht sicherlich in einer Stunde).

Ich hatte so um die fünf Jahre im Kopf. Das soll aber auch keine detaillierte Vorstellung sein, oder ein Einführungsvortrag, und erst recht nicht vollständig. Sondern so die vier, fünf größten Neuerungen, die es mal grob zu erwähnen und zu zeigen gibt wäre doch sicherlich in einer Stunde zu machen.

[Der schöne Günther]

Genau das tun doch eigentlich immer die Embarcadero-Roadshows, oder?

[Benedikt Magnus]

Zitat von Der schöne Günther:

Genau das tun doch eigentlich immer die Embarcadero-Roadshows, oder?

Ja, aber die sind zu begrenzt, speziell und auf das Unternehmen ausgelegt. Ich dachte mehr an Allgemeines und wie sich das mit Delphi umsetzen ließe.

[mikhal]

@Benedict Magnus:
Ich denke, da wärest du besser bei den diversen Stammtischen bzw. Meetups aufgehoben, dort kann man solche Themen diskutieren. Einen Erfahrungsaustausch kann man dort mit Sicherheit eher erhalten. Bei dir steht Euskirchen als Wohnort drin, da böte sich die Meetup-Gruppe Köln-Delphi-Meetup an.

Grüße
Mikhal

[Nersgatt]

Auch wenn ich mich jetzt vielleicht als Doof oute, weil es eigentlich Grundlagenwissen ist, aber ich hab das Thema der Pfade (Suchpfad, Bibliothekspfad, DCP-Ausgabeverzeichnis) usw. nie wirklich zu 100% verstanden. Was muss ich machen, damit er mir nicht immer alle Komponenten mit erzeugt, ich aber debuggen kann, usw. Und wenn die Komponenten selbst compilieren möchte?

Wenn es dazu eine Session gäbe, die diese Grundlagen vermittelt, würde ich mir die auf jeden Fall anschauen.

[Der schöne Günther]

Wie sieht es eigentlich mit Aufzeichnungen (zumindest Audio) der Vorträge aus? Ist da etwas geplant?

[himitsu]

Zitat von Der schöne Günther:

Wie sieht es eigentlich mit Aufzeichnungen (zumindest Audio) der Vorträge aus? Ist da etwas geplant?

Eine Aussage gab es dazu mal von Daniel, vor paar Jahren.
"Ist uns zu aufwändig und die fehlende Technik, aber wenn jemand das machen will, dann darf er gern." (so grob zusammengefasst zitiert)

Wenn das dann ebenfalls via Mail verteilt wird, so wie die Arbeitsunterlagen der verschiedenen Workshops, dann wäre das bestimmt OK.
Es gab da auch schonmal die Frage nach LiveStreams, für Jene die nicht persönlich kommen können.

Aber wie das jetzt mit dem LiveStream (vermutlich das besser für ein kleines Endgeld, was auch an den Veranstalter geht, anstatt dem Eintrittsgeld)
oder einem nachträglichen "offentlichen" Download/Youtube/usw., so das sollte wohl besser nochmal "rechtlich" abgeklärt werden.


Meine persönliche Meinung:
Man könnte daraus bestimmt einen schönen Youtube-Kanal machen (DP-Downloadseite, Youtube, Vimeo, Dailymotion oder sonstwo),
um später in Ruhe sich auch das der letzten Jahre nochmal anzusehn, wenn man was wissen möchte.

[jaenicke]

Zitat von Nersgatt:

aber ich hab das Thema der Pfade (Suchpfad, Bibliothekspfad, DCP-Ausgabeverzeichnis) usw. nie wirklich zu 100% verstanden. Was muss ich machen, damit er mir nicht immer alle Komponenten mit erzeugt, ich aber debuggen kann, usw. Und wenn die Komponenten selbst compilieren möchte?

Hmm, das ist nicht viel... Vielleicht schaffe ich das mal als Forenbeitrag zu verfassen...

[Rollo62]

Hatte schon jemand "Mobile Plattformen" erwähnt ?
Meinetwegen aber kein 1-2-3 und das erste Button draufwerfern, sondern richtig ans Eingemachte.
Tips-Tricks-Fallstricke ...
Was geht, was geht nicht ...

Die 1-2-3 Go Anleitungen im DocWiki sind eigentlich schon sehr gut, das bräuchte man vieleicht nicht unbedingt.

Rollo

[Phoenix]

Zitat von Sherlock:

Zitat von Nersgatt:

Zitat von mikhal:

Eine praktische Einführung in Unit-Testing. Wie geht man da ran? Da ist bei mir der Zug irgendwann vorbeigefahren!

Und das gern im Zusammenhang mit Datenbankanwendungen.

Oder auch mit viel Oberfläche bzw. Benutzerinteraktion. Wie man das mit Unit-Tests testet war mir immer ein Rätsel.

Tja, Sherlock, das kann ich sogar als nicht-mehr-Delphianer beantworten

Kurzum: Oberflächen testet man Prinzipbedingt schon nicht mit Unit-Tests. Ein Unit-Test testet per Definition eine kleinstmögliche Einheit (Unit), das hat mit der Delphi-Unit nichts gemeinsam. Ein einzelner Unit-Test testet genau einen Effekt einer Methode. Hat die Methode mehrere Effekte, testet man jeden einzelnen mit einem einzelnen Unit-Test. Man kann auch den Konstruktor als Unit betrachten und dann den Initialzustand des Objektes überprüfen.

Sobald Du mehr als eine Klasse in einem Test abklopfst, bist Du schon aus der Welt der Unit-Tests raus und in der Welt der Integration-Tests angekommen.

Das funktioniert anfangs noch so ähnlich wie Unit-Tests - zumindest wenn alle am Test beteiligten Klassen noch in Deiner Kontrolle / in Deinem Projekt sind. Und solange man nicht weiter ausholt kann man die auch noch so schreiben wie die echten Unit-Tests.

Sobald eine Klasse in Deinem Integration-Test dabei aber die Grenzen Deines SUT (System under Test) verlassen (Datenbankzugriffsklassen, GUI-Klassen die native Apis callen wie die VCL, Netzwerkzugriffsklassen), dann ist es mit der einfachen Testbarkeit vorbei, weil Du dann immer darauf achten musst, dass das externe System (die Datenbank, das Ding im Netzwerk auf das zugegriffen wird, das UI-System) vor jedem einzelnen Test in einen wohldefinierten Zustand gebracht wird.

Am Ende des Tages verbringst Du bei dieser Art zu testen mehr Zeit damit, externe Systeme zu managen und Code zum Vorbereiten der Tests zu schreiben, als eigentlicher Code und als Testcode (der bei normalen Unit-Tests üblicherweise schon ein Vielfaches des zu testenden Codes beträgt). Insbesondere bei Datenbanken (herstellen der Test-DB etc.) und bei Services (noch schlimmer wenn die auch ne DB brauchen) ist man da gerne auf verlorenem Posten.

Tools wie z.B. TestComplete oder Ranorex können da leider auch nur bedingt helfen, und bringen alle ihre eigene Komplexität mit. Im Web siehts da ein klein bisschen besser aus, aber zum Trost auch nicht viel.

In der Praxis würde ich daher in den meisten Fällen vorschlagen, so viel wie möglich MVC zu fahren und dabei vor allem das M und den C sehr gut Unit- und Integration zu testen. Bei der View wird dann ausschließlich auf Model-Binding gesetzt (genau gar keine Logik dort) und darauf vertraut, dass der Lieferant seine UI-Elemente selber vernünftig getestet hat, und das eigentliche UI gar nicht automatisiert zu testen. Das einzige was man dann nämlich mit dem UI-Test testen würde wäre, ob ein Wert im Model auch richtig angezeigt wird und Events vom UI richtig am Controller ankommen. Das hat aber mit der Programmlogik an sich nichts zu tun. Und die Programmlogik, die Testbar im Controller bzw. dahinter (Services, Repositories etc.) sitzen sollte, hat dann mit dem UI nichts mehr zu tun und kann wirklich intensiv und gut getestet werden.