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

[Daniel]

Moin,

es ist schon eine spannende Sache mit der Delphi-Community. ;-) Da will man eine Konferenz ausrichten (www.forentage.de) und fragt in die Runde, wer sich denn vorstellen könnte, einen Vortrag zu halten. Das Feedback ist grundsätzlich gut, doch der eine oder andere mögliche Referent fragte zurück, was denn für Themen gewünscht wären. Jetzt kann ich natürlich meine eigene heimliche, private Wunschliste durchgehen - aber viel spannender wäre ja die Frage, was IHR EUCH wünscht.

Mit diesem Beitrag möchte eich zu einem offenen Austausch anregen, welche Themen auf den Foren-Tagen für Euch interessant wären. Und umgekehrt gilt natürlich auch: Wird hier ein Thema genannt, mit dem sich wer identifizieren kann, dann ist er herzlich eingeladen, "hier!" zu schreiben und unserem Call for Papers zu folgen. ;-)

[jaenicke]

Mich würde interessieren wie in der Praxis eine gute Softwaredokumentation aussehen könnte. Insbesondere die Tools dafür. Und das ganze von der Aufnahme der Anforderungen über die Planung bis hin zur Endkunden-, Support und Entwicklerdoku. Am besten noch mit einer Übersicht über die Entwicklungsstände für die Projektleitung.

Puh, ganz schön viele Anforderungen... ;-)

Zum Hintergrund:
Wir nutzen JIRA (für Bugreports, Featurerequests, usw.), ein Wiki (zur Dokumentation für Einrichtung und Support, aber auch für Entwicklungsthemen), Documentation Insight (für API- und Quelltextdoku), draw.io (für Planungsdiagramme), ein Help Authoring Tool für die Endkundenhilfe und pflegen noch dazu ein Handbuch (das wir an Behörden ausliefern usw.).
Das ganze erfüllt zwar durchaus seinen Zweck, aber es ist halt nicht so schön "aus einem Guss" wie man so schön sagt. Außerdem erfordert es einiges an Arbeit, es gibt viele mehrfache Inhalte, ...

Wenn dafür jemand eine schöne Lösung vorstellen könnte, wäre das echt toll. Und um das zu betonen: Die Lösung(en) dürfen auch ruhig Geld kosten. Hauptsache sie sind gut.

[Luckie]

Zitat:

Zitat von jaenicke (Beitrag 1375014)

Mich würde interessieren wie in der Praxis eine gute Softwaredokumentation aussehen könnte.

Praxis und Softwaredokumentation. Finde den Fehler. :mrgreen: Nein Scherz bei Seite.

Ich würde mir wünschen, wenn ich denn teilnehmen würde, einen Vortrag zu hören über den Einstieg in die Smartphone Programmierung. Welche IDE's gibt es? Gibt es günstige bzw. frei IDE's? Wie testet man praktisch eine App? Wie gehe ich mit denen um? Beispiel ein 'Hello world' für Android. Gibt es da was von Ratioph...öhm mit Delphi/Pascal? OK, der Zug ist schon etwas länger abgefahren, aber das würde mich so interessieren, der der den Zug irgendwie verpasst hat. :roll:

[mikhal]

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

Grüße
Mikhal

[Nersgatt]

Zitat:

Zitat von mikhal (Beitrag 1375025)

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.

[Sherlock]

Zitat:

Zitat von Nersgatt (Beitrag 1375028)

Zitat:

Zitat von mikhal (Beitrag 1375025)

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.

Sherlock

[Der schöne Günther]

Was ist eigentlich dieses Data-Snap-Gedöns? Ich habe nie verstanden was das eigentlich ist und warum und wo ich das einsetzen sollte. Vielleicht ein praktisches Beispiel ohne Hallo Welt und Taschenrechner?

[mkinzler]

Ist Embarcaderos Multi-Tier Lösung

[Sherlock]

Zitat:

Zitat von Der schöne Günther (Beitrag 1375040)

Vielleicht ein praktisches Beispiel ohne Hallo Welt und Taschenrechner?

Das wünsche ich mir für alle Beispiele. Schon immer.

Sherlock

[Jumpy]

Was zum Thema Interfaces?
- Wann und warum sinnvoll?
- Warum bringt der vermeindliche(?) Overhead trotzdem Vorteile?
- ...

[Mavarik]

Zitat:

Zitat von Jumpy (Beitrag 1375046)

Was zum Thema Interfaces?
- Wann und warum sinnvoll?
- Warum bringt der vermeindliche(?) Overhead trotzdem Vorteile?
- ...

Ahh mein Thema...:stupid:

[stahli]

Trennung von Daten und Businesslogik unter RAD und Einsatz von Databinding...

Praxisnahe Umsetzung zur schnelleren und einfacheren Projektrealisierung (weniger zur Koordinierung von mehreren Teams).

[Mavarik]

"Naturgemäß" halte ich ja eine Session, die mit FMX zu tun hat, bzw. auf FMX aufsetzt...

Wer meinen Blog liest hat sicherlich schon gesehen, dass ich eine entsprechende Schulung vorbereite... Eines dieser Themen könnte ich natürlich in verkürzter Form auf den Forentagen halten...

Ist ein Vortrag zum Thema FMX überhaupt gewünscht?

Mavarik :coder:

[Nersgatt]

Zitat:

Zitat von Mavarik (Beitrag 1375053)

Ist ein Vortrag zum Thema FMX überhaupt gewünscht?

Für meinen Geschmack sind die Delphitage in den letzten Jahren zu FMX-lastig geworden.
Ich setze FMX nicht ein, daher finde ich die Vorträge, die auf FMX aufbauen nicht wirklich interessant.

Gibt es irgendwo eine Umfrage, wie viel FMX-Anteil in der Praxis die Delphicommunity hat? Wäre mal ne Umfrage wert.

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1375053)

Ist ein Vortrag zum Thema FMX überhaupt gewünscht?

Was mich zum Beispiel interessieren würde, wäre das Thema komplett eigene Controls, Scrollen und Styling von dynamisch erstellten Inhalten (sprich ähnlich wie eine Listbox mit Bildern in den Zeilen). Ich bin am Ende auf schlichtes Zeichnen wie in der VCL ausgewichen, was auch sehr gut funktioniert, aber ich weiß durchaus, dass es auch andere Lösungen geben würde. Zumindest als ich damit angefangen habe, habe ich aber Null Informationen zu dem Thema gefunden... und musste dann mangels Zeit abbrechen und eben auf Canvas ausweichen.

// EDIT:

Zitat:

Zitat von Jumpy (Beitrag 1375046)

Was zum Thema Interfaces?
- Wann und warum sinnvoll?
- Warum bringt der vermeindliche(?) Overhead trotzdem Vorteile?
- ...

Dazu gibt es schon viel Material, aber da trotzdem viele Interfaces nicht einsetzen, kann ein solcher Vortrag vielen etwas bringen. Das sehe ich auch so.
Wenn ich unsere aktuelle Interface-basierte Codebasis mit der alten vergleiche... da liegen Welten dazwischen.

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1375040)

Was ist eigentlich dieses Data-Snap-Gedöns?

DataSnap (nutzte früher intern DBX/dbExpress)
http://docwiki.embarcadero.com/RADSt...gen_entwickeln
http://docwiki.embarcadero.com/RADSt...nd_Architektur
http://docwiki.embarcadero.com/RADSt...dung_verwenden

oder Neuer die Enterprise Mobility Services (EMS)
http://docwiki.embarcadero.com/RADSt..._Services_(EMS)


Ist eine Middleware -> verteilte Programmlogic: Code in einem Server ausführen, statt im Programm (Clienten)

[Mavarik]

Zitat:

Zitat von Nersgatt (Beitrag 1375054)

Für meinen Geschmack sind die Delphitage in den letzten Jahren zu FMX-lastig geworden.

Vielleicht weil FMX die Zukunft ist...:twisted:

Zitat:

Zitat von jaenicke (Beitrag 1375057)

Was mich zum Beispiel interessieren würde, wäre das Thema komplett eigene Controls, Scrollen und Styling von dynamisch erstellten Inhalten (sprich ähnlich wie eine Listbox mit Bildern in den Zeilen).

Gerne... in Meiner App gibt es außer den TabContols, Toolbars, den List-Boxen/Views und dem "MainLabel" kein Control das in der IDE auf ein Formular geklickt wurde... Auch habe ich im OI nichts eingestellt...

Alles andere kommt "On The Fly"...

[DeddyH]

Zitat:

Zitat von Mavarik (Beitrag 1375063)

Vielleicht weil FMX die Zukunft ist...:twisted:

Ganz ehrlich: meine nicht. Vielleicht in 4 - 5 Jahren, wenn endlich die ganzen Kinderkrankheiten vielleicht mal verschwunden sind, zum aktuellen Zeitpunkt ist mein Frustfaktor einfach zu hoch.

[Mavarik]

Zitat:

Zitat von DeddyH (Beitrag 1375064)

Zitat:

Zitat von Mavarik (Beitrag 1375063)

Vielleicht weil FMX die Zukunft ist...:twisted:

Ganz ehrlich: meine nicht. Vielleicht in 4 - 5 Jahren, wenn endlich die ganzen Kinderkrankheiten vielleicht mal verschwunden sind, zum aktuellen Zeitpunkt ist mein Frustfaktor einfach zu hoch.

[OT]
Du hast keinen Mitbewerber?
Kein Kunde der "wo anders" kauft, weil die andere Firma eine App hat...?
[/OT]

[stahli]

[OT]
Apps kann man ja auch mit anderen Werkzeugen entwickeln als mit FMX.
[/OT]

[DeddyH]

Genau ;)

[SneakyBagels]

Zitat:

Für meinen Geschmack sind die Delphitage in den letzten Jahren zu FMX-lastig geworden.

FMX ist meiner Meinung nach nicht mehr als ein Proof of Concept. Zu viele Bugs, die wahnsinnig teuer verkauft werden.
Aber man will ja konkurrenzfähig bleiben, also schmeißt man das auf den Markt. Nur muss man auch bedenken: je mehr Leute durch Bugs frustriert sind, desto mehr hauen ab und verbreiten schlechte Mundpropaganda.
FMX sollte besser nochmal komplett raus und erst wieder rein und zum Verkauf, wenn es brauchbar ist.

[Sherlock]

Ganz so schlimm würde ich FMX mittlerweile nicht mehr beurteilen. Ich verkaufe mit FMX geschrieben Software, die sehr stabil läuft, einfach zu warten ist, und recht einfach auf den drei von mir favorisierten Plattformen (Win, macOS, iOS) zum laufen gebracht werden kann. Mit dem gleichen Projekt.

Sherlock

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1375081)

FMX ist meiner Meinung nach nicht mehr als ein Proof of Concept. Zu viele Bugs, die wahnsinnig teuer verkauft werden.

Es hat sich in den letzten Jahren an vielen Stellen viel getan. Dazu zählt FMX, aber dazu zählen auch Generics. Wie wenig man damit machen konnte, habe ich gerade erst bei der Rückportierung eines Open Source Projekts gemerkt. Je weiter ich zurück gegangen bin desto mehr Workarounds brauchte ich... vorher war der Quelltext viel schöner...

Auf welcher Delphiversion basiert denn deine Aussage?

[Luckie]

Die Diskussion über FMX gehört, nicht ganz hier her. Kommt bitte wiede rzurück zum Thema.

[OlliWW]

Mich würde mal das Thema interessieren:
Wie setze ich die Delphi IDE in einem großen Unternehmen mit EINEM großen Projekt ein.

Wir stehen immer wieder vor folgenden Fragen:
- Wie kriegen wir es hin, dass alle Entwickler die gleichen "Einstellungen" / Komponenten nutzen (nein, nicht alle Entwickler [Azubis, ..] sind in der Lage dies selbst zu pflegen)
- Wie geht man mit der IDE mit großen Projekten ( > 2 Mio Zeilen) um => was gibt es hier für Best practises damit man nach einem "." nicht Kaffee holen muss bis das Kontextmenü aufgeht, Tipps zur Perfomance allgemein, wie Beschleunige ich den Compile-Vorgang (unsere Entwickler sind teilweise so frustiert von der IDE, dass sie im Notepad++ programmieren)

[Bernhard Geyer]

Zitat:

Zitat von OlliWW (Beitrag 1375126)

Wir stehen immer wieder vor folgenden Fragen:
- Wie kriegen wir es hin, dass alle Entwickler die gleichen "Einstellungen" / Komponenten nutzen (nein, nicht alle Entwickler [Azubis, ..] sind in der Lage dies selbst zu pflegen)

Wir machen das so:
- Alle (Kauf/OS/Selbstentwickelten) Komponenten liegen ebenfalls im CVS
- Die Kompoenten werden über ein Script (*.bat-Datei mit Aufruf msbuild der entsprechenden dproj-Dateien
- Der Entwickler muss einmalig alle erstellten BPL in der IDE aktivieren

Wenn sich Komponenten ändern die sich auf die IDE auswirken (neue Properties) so muss nur die Batch-Datei ausgeführt werden.
Die aktualisierten Komponentensourcen wird man ja wohl regelmäßig aus dem CVS auschecken.

Zitat:

Zitat von OlliWW (Beitrag 1375126)

- Wie geht man mit der IDE mit großen Projekten ( > 2 Mio Zeilen) um => was gibt es hier für Best practises damit man nach einem "." nicht Kaffee holen muss bis das Kontextmenü aufgeht, Tipps zur Perfomance allgemein, wie Beschleunige ich den Compile-Vorgang (unsere Entwickler sind teilweise so frustiert von der IDE, dass sie im Notepad++ programmieren)

Diese Probleme kennen wir nicht. Haben nur ein paar Tips angewand
- DDevExtension und Co. eines bekannten Entwicklers installieren
- Von der IT den Virenscanner so einstellen lassen das die dcu-Dateien nicht geprüft werden

Rebuildzeiten sind für ein 2 Mio-Zeilenprojekt zwischen 65 Sekunden (Meistens beim ersten Erstellen nach Login) und 15 Sekunden. Externe Map und Debug-Dateien brauchen dann auch nochmal 5-10 Sekunden (sind aber nur für RemoteDebugging und Co nötig.) Zeiten nach Drücken von "." sind oft 1-2 Sekunden und "alle Stunde" bis zu einer Minuten. Alles bei XE6

[jaenicke]

Zitat:

Zitat von OlliWW (Beitrag 1375126)

- Wie geht man mit der IDE mit großen Projekten ( > 2 Mio Zeilen) um => was gibt es hier für Best practises damit man nach einem "." nicht Kaffee holen muss bis das Kontextmenü aufgeht, Tipps zur Perfomance allgemein, wie Beschleunige ich den Compile-Vorgang (unsere Entwickler sind teilweise so frustiert von der IDE, dass sie im Notepad++ programmieren)

Der wichtigste Tipp:
Nicht alle Quelltextdateien blind in das Projekt werfen...
Seit wir ein Package vorkompilieren mit gemeinsamen Dateien mehrerer Projekte und alle Komponenten ebenfalls ist die IDE Performance deutlich besser und der Kompiliervorgang der Projekte logischerweise deutlich schneller, weil nicht mehr alles immer neu kompiliert werden muss.

Das ist glaube ich auch ein gutes Thema für eine Frage hier im Forum.

Zitat:

Zitat von OlliWW (Beitrag 1375126)

- Wie kriegen wir es hin, dass alle Entwickler die gleichen "Einstellungen" / Komponenten nutzen (nein, nicht alle Entwickler [Azubis, ..] sind in der Lage dies selbst zu pflegen)

Wie Bernhard auch geschrieben hat:
Komponenten und Quelltexte werden ausgecheckt, per Buildskript kompiliert, fertig.
Dann bleiben nur noch wenige Einstellungen übrig, nämlich Bibliothekspfad, Suchpfad und die Editorbreite. Wird beim Bibliothekspfad nix eingestellt, funktioniert schlicht der Build nicht. Viel falsch machen geht daher nicht.

Aber wie gesagt:
Mach daraus doch besser eine Frage hier im Forum, da bekommst du glaube ich deutlich mehr Feedback als aus einem Vortrag einer einzelnen Person.

[Benedikt Magnus]

Wenngleich ich selbst leider auch nicht teilnehmen kann, würde ich mir mal einen Überblick über die Neuerungen in der Programmierung der letzten Jahre und wie die Umsetzung mit Delphi aussieht wünschen. So jeweils eine kurze Vorstellung der wichtigsten Änderungen in der "Branche" mit kleinem Beispiel ab und an wäre sehr interessant und könnte bei so manchem "abgefahrenen Zug" behilflich sein. :-D

[Mavarik]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1375149)

Wenngleich ich selbst leider auch nicht teilnehmen kann, würde ich mir mal einen Überblick über die Neuerungen in der Programmierung der letzten Jahre und wie die Umsetzung mit Delphi aussieht wünschen. So jeweils eine kurze Vorstellung der wichtigsten Änderungen in der "Branche" mit kleinem Beispiel ab und an wäre sehr interessant und könnte bei so manchem "abgefahrenen Zug" behilflich sein. :-D

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). 8-)

[Benedikt Magnus]

Zitat:

Zitat von Mavarik (Beitrag 1375153)

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). 8-)

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:

Zitat von Der schöne Günther (Beitrag 1375162)

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:

Zitat von Der schöne Günther (Beitrag 1375177)

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:

Zitat von Nersgatt (Beitrag 1375174)

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:

Zitat von Sherlock (Beitrag 1375038)

Zitat:

Zitat von Nersgatt (Beitrag 1375028)

Zitat:

Zitat von mikhal (Beitrag 1375025)

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.