%0 Journal Article %1 drarnhold2012dekonstruktion %A Dr. Arnhold, Andreas %A Frenzel, Leif %D 2012 %J OBJEKTspektrum %K integrationstest test unit-test %N 4 %P 44-48 %T Dekonstruktion von Integrations- zu Unit-Tests %U http://www.andrena.de/system/files/arnold_frenzel_DEKONSTRUKTION_0.pdf %X Die Autoren stellen fest, dass in der Praxis häufig ein Übergewicht an Integrationstests im Vergleich zu Unit Tests vorliegt. Sie analysieren im ersten Teil des Artikels die Ursachen dafür auf Basis ihrer persönlichen Projekterfahrungen. Im zweiten Teil stellen Sie Wege vor wie dieser Überhang konstruktiv beseitigt werden kann. Am Ende steht das Ziel umfangreicher Unit Tests und notwendiger Integrationstest.

@article{drarnhold2012dekonstruktion, abstract = {Die Autoren stellen fest, dass in der Praxis häufig ein Übergewicht an Integrationstests im Vergleich zu Unit Tests vorliegt. Sie analysieren im ersten Teil des Artikels die Ursachen dafür auf Basis ihrer persönlichen Projekterfahrungen. Im zweiten Teil stellen Sie Wege vor wie dieser Überhang konstruktiv beseitigt werden kann. Am Ende steht das Ziel umfangreicher Unit Tests und notwendiger Integrationstest. }, added-at = {2013-08-26T21:11:59.000+0200}, author = {Dr. Arnhold, Andreas and Frenzel, Leif}, biburl = {https://www.bibsonomy.org/bibtex/2c5435b07a37de6d81a90a4eacfdf58e4/funthomas424242}, description = {Ich finde den Artikel sehr interessant, den er bringt einen kleinen Aha Effekt - ach darum haben wir immer soviel Aufwand im Systemtest, ja stimmt das hab ich auch schon vorgeschlagen und aus genau den genannten Gründen. Man denkt sich nichts dabei und schleichend werden die schwergewichtigen Tests immer mehr. Einmal mit kühlen Kopf drüber nach gedacht und es fällt wie Schuppen von den Augen. Einige Ursachen seien exemplarisch erwähnt: Entwickler lassen sich für gewöhnlich leichter motivieren schwergewichtige Tests zu schreiben als Unit Tests. Ein Testfall wird gern so ausgebaut, dass er gleich noch Teile der Nachbarfunktion mit testet (dadurch wird er schwergewichtig). Im Gegenzug wird dann die Nachbarfunktion nicht mehr so intensiv mit Unit Tests abgedeckt. Systemtests erfordern projektinterne technische Arbeiten oder das Ausprobieren neuer Technologien und bieten so auch eine willkommene Abwechslung für Entwickler. Als Lösung wird das Untersuchen der Integrationstests vorgeschlagen. Sie werden untersucht ob sie nur einen Test oder mehrere realisieren. Anschließend werden diese zerteilt - nicht verworfen - in Unit Test und Integrationstest mit dem Ziel das jeder Test sich auf seinen Scope beschränkt. In der Praxis sind dazu oft Rahmenbedingungen anzupassen, z.B. der Entwicklungsprozess. Der Prozess der Dekonstruktion benötigt einen Blick für leichtgewichtig zu testende Codestellen. Gute Clean Code Strategien führen laut den Autoren letztlich auch zu gut testbaren Kode und unterstützen somit die Dekonstruktion. Folgende Hinweise zur Verbesserung der Testbarkeit werden gegeben: 1. Kein Berechnungslogik direkt in der GUI sondern stets in Klassen auslagern. 2. Zugriffe auf andere Systemkomponenten über Schnittstellen abstrahieren um Unit Tests zu ermöglichen. 3. Datenbankzugriffe über eine Repository Klasse realisieren und nur diese gegen die Datenbank testen. Alle anderen Tests benutzen ein RepositoryMock. 4. Keine Abhängigkeiten zwischen den Tests. 5. Zum Test von Nebenläufigkeit wird diese in spezielle Module separiert und über spezielle Frameworks getestet. }, interhash = {7b0e11aeacc11949fc49174b734f4772}, intrahash = {c5435b07a37de6d81a90a4eacfdf58e4}, journal = {OBJEKTspektrum}, keywords = {integrationstest test unit-test}, number = 4, pages = {44-48}, timestamp = {2013-08-26T21:33:30.000+0200}, title = {Dekonstruktion von Integrations- zu Unit-Tests}, url = {http://www.andrena.de/system/files/arnold_frenzel_DEKONSTRUKTION_0.pdf}, year = 2012 }