Testwissen für Java-Entwickler

Testwissen für Java-Entwickler

Kai Spichale


In diesem Teil werden die Eigenschaften der testgetriebenen und der verhaltensgetriebenen Entwicklung vorgestellt. Best Practices für Unit Tests und Frameworks zur Ergebnisverifikation werden beschrieben. Im zweiten Teil werden unterschiedliche Teststile vorgestellt, denn die in diesem Artikel verwendeten Tests nutzen zur Verifikation ausschließlich den Zustand der Objekte, nicht aber deren Interaktionen bzw. Verhalten. Der dritte Teil widmet sich ganz der Test- und Build-Automatisierung, um von den Unit und Integrationstests im Rahmen einer kontinuierlichen Integration profitieren zu können.

ArtikelserieTeil 1: Eigenschaften von TDD und BDD, Best Practices für Unit TestsTeil 2: TeststileTeil 3: Test- und Build-Automatisierung

Softwareprojekte versuchen meist etwas zu realisieren, was noch nie zuvor realisiert wurde – jedenfalls nicht vom gleichen Team oder von der gleichen Organisation. Die unbekannten Unbekannten eines komplexen Softwareprojekts können nur schwer oder gar nicht antizipiert werden. Deswegen sind Softwareprojekte auch Lern- und Erkenntnisprozesse mit Überraschungen und unerwarteten Änderungen. In diesem Kontext sind Tests unverzichtbar, denn sie sind zahlreich und unterstützen das Entwicklungsteam dabei, ein System an neue Anforderungen anzupassen. Eine gute Testsuite mit hoher Testabdeckung kann ein Sicherheitsnetz bilden, das Regressionsfehler aufdeckt. Ohne das Feedback einer Testsuite könnten sich andernfalls unbemerkt Fehler einschleichen, wenn neue Features hinzugefügt oder andere angepasst werden.

Die testgetriebene Entwicklung (Test-driven Development, TDD) kann anhand drei einfacher Regeln definiert werden [2]:

Produktiver Code darf ohne fehlschlagende Tests nicht geschrieben werden.Nicht mehr Testcode als unbedingt notwendig ist, um einen Fehler anzuzeigen, darf geschrieben werden.Nicht mehr produktiver Code als unbedingt notwendig darf für den Erfolg des fehlgeschlagenen Tests geschrieben werden.

Bei TDD dienen Tests nicht nur dazu, um Fehler vom Endbenutzer fernzuhalten. Vielmehr gehören sie zum (Mikro-)Entwurf [3]. Wer mit einem Test die Entwicklung eines neuen Features beginnt, ist gezwungen, sich Klarheit über seine Absichten zu verschaffen und diese eindeutig im Test zu beschreiben. Ein zu starrer oder unscharfer Entwurf ist für dieses Vorgehen ungeeignet und fällt gleich zu Beginn auf. Eine frühe Entwurfsverbesserung ist einfacher durchführbar als eine spätere, wenn bereits produktiver Code geschrieben wurde. Die Tests bilde...

Testwissen für Java-Entwickler

Testwissen für Java-Entwickler

Kai Spichale


In diesem Teil werden die Eigenschaften der testgetriebenen und der verhaltensgetriebenen Entwicklung vorgestellt. Best Practices für Unit Tests und Frameworks zur Ergebnisverifikation werden beschrieben. Im zweiten Teil werden unterschiedliche Teststile vorgestellt, denn die in diesem Artikel verwendeten Tests nutzen zur Verifikation ausschließlich den Zustand der Objekte, nicht aber deren Interaktionen bzw. Verhalten. Der dritte Teil widmet sich ganz der Test- und Build-Automatisierung, um von den Unit und Integrationstests im Rahmen einer kontinuierlichen Integration profitieren zu können.

ArtikelserieTeil 1: Eigenschaften von TDD und BDD, Best Practices für Unit TestsTeil 2: TeststileTeil 3: Test- und Build-Automatisierung

Softwareprojekte versuchen meist etwas zu realisieren, was noch nie zuvor realisiert wurde – jedenfalls nicht vom gleichen Team oder von der gleichen Organisation. Die unbekannten Unbekannten eines komplexen Softwareprojekts können nur schwer oder gar nicht antizipiert werden. Deswegen sind Softwareprojekte auch Lern- und Erkenntnisprozesse mit Überraschungen und unerwarteten Änderungen. In diesem Kontext sind Tests unverzichtbar, denn sie sind zahlreich und unterstützen das Entwicklungsteam dabei, ein System an neue Anforderungen anzupassen. Eine gute Testsuite mit hoher Testabdeckung kann ein Sicherheitsnetz bilden, das Regressionsfehler aufdeckt. Ohne das Feedback einer Testsuite könnten sich andernfalls unbemerkt Fehler einschleichen, wenn neue Features hinzugefügt oder andere angepasst werden.

Die testgetriebene Entwicklung (Test-driven Development, TDD) kann anhand drei einfacher Regeln definiert werden [2]:

Produktiver Code darf ohne fehlschlagende Tests nicht geschrieben werden.Nicht mehr Testcode als unbedingt notwendig ist, um einen Fehler anzuzeigen, darf geschrieben werden.Nicht mehr produktiver Code als unbedingt notwendig darf für den Erfolg des fehlgeschlagenen Tests geschrieben werden.

Bei TDD dienen Tests nicht nur dazu, um Fehler vom Endbenutzer fernzuhalten. Vielmehr gehören sie zum (Mikro-)Entwurf [3]. Wer mit einem Test die Entwicklung eines neuen Features beginnt, ist gezwungen, sich Klarheit über seine Absichten zu verschaffen und diese eindeutig im Test zu beschreiben. Ein zu starrer oder unscharfer Entwurf ist für dieses Vorgehen ungeeignet und fällt gleich zu Beginn auf. Eine frühe Entwurfsverbesserung ist einfacher durchführbar als eine spätere, wenn bereits produktiver Code geschrieben wurde. Die Tests bilde...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang