• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Ruth Richter & Pauline Schulze 13. Juni 2023

Effizientes Testen auf allen Stufen

Kleine Ressourcen, große Anforderungen

Wer testet wann?

Widmen wir uns zunächst der Brandbreite bei den Faktoren Rollenverteilung und Zeitpunkt. Beides kann innerhalb eines Teams stark variieren. Das eine Extrem der Rollenverteilung favorisiert klar getrennte Funktionalitäten zwischen Entwicklerin und dezidiertem Test Automation Engineer. Der Vorteil liegt dabei in der Expertise: Die Entwicklung kann den Core-Code zur Perfektion treiben, ohne viel nach rechts und links schauen zu müssen, der Test wiederum prüft mit eigenem Verständnis und Test-Expertise das fertige Stück Software auf Herz und Nieren – codenah mit WhiteBox-Tests und/oder "von außen" mit BlackBox-Tests.

Am anderen Ende der Skala stehen Teams, in denen es – ganz nach agilem Ansatz – überhaupt keine Rollen mehr gibt. Jede macht alles, jede entwickelt und jede testet auf allen Stufen. Somit benötigt man hauptsächlich Allrounder, Generalisten, die sich schnell auf jede Aufgabe einstellen müssen und damit einen breiten Kenntnisstand entwickeln.

Auch hinsichtlich des Zeitpunktes, wann der Test ansetzt, gibt es eine breite Varianz. In früheren Zeiten wurden codenahe Unit- und Integrationstests zwar während der Entwicklung durchgeführt, alle Blackbox-Tests starteten aber erst, nachdem die Software komplett fertig gestellt wurde – waren also nachgelagert. Es erübrigt sich fast zu sagen, dass der Umbau falsch interpretierter Funktionalitäten im Anschluss hohe Kosten verursacht hat. Diese Vorgehensweise hat sich als nicht besonders effizient herausgestellt – auch wenn die Entwicklungszeit an sich vielleicht kürzer erschien.

Das andere zeitliche Extrem stellt den Test voran. Dies kann so weit gehen, dass alle Tests, Unit- (TDD-Ansatz) und auch Acceptance-Tests (BDD-Ansatz) unmittelbar vor dem Coden einer Komponente oder eines fachlichen Features aufgestellt werden. Das kann – und da kommen wir noch einmal auf die Rollenverteilung zurück – sowohl von allen Teammitgliedern als auch ausschließlich vom Test Automation Engineer durchgeführt werden. Der Vorteil dieses Ansatzes liegt darin, dass schon vor der ersten Zeile Code klar ist, was die Komponente (ausschließlich) leisten soll und/ oder der Kunde seine Zustimmung oder sein Veto zur fachlichen Umsetzung gegeben hat. Der Nachteil liegt darin, dass diese Arbeitsweise anfänglich sperrig erscheinen mag und einer sehr gut durchdachten Planung bedarf. Zwischen den angeführten Extrempunkten bezüglich Rollenverteilung und zeitlicher Anordnung liegen unzählige Abstufungen.

Rollenverteilung und Zeitpunkt – Best Practices

Wie ein Team testet, hängt grundlegend an Faktoren wie dem unterschiedlichen Erfahrungshorizont der Mitarbeiter, Größe, Selbstverständnis und Prinzipien des Teams und auch der Beschaffenheit des Projektes. So lässt sich kein allgemeingültiger Ansatz propagieren, der jedes Team gleichermaßen zum Erfolg führt. Dennoch kann jedes Team seine Effizienz steigern, indem es folgende Grundsätze berücksichtigt.

• Menschen arbeiten in den Bereichen schneller, in denen sie sich gut auskennen und für die sie sich interessieren. Dies kann zum Beispiel eine tiefe Test-Erfahrung sein, wie bei einer dezidierten Testerin, aber auch wie bei einer sehr testerfahrenen und -affinen Entwicklerin. Das Team sollte also genau hinschauen, bei wem die Test-Stärken und Interessen liegen.
• Das Vier-Augen-Prinzip steigert die Effizienz. Wird eine Funktionalität vom gleichen Menschen entwickelt und in Gänze getestet, verlieren wir den Mehrwert für die Funktionalität. Der Test hätte zum Beispiel keine Chance, falsch verstandene Anforderungen zu erkennen. Um redundantes und damit ineffizientes Handeln zu vermeiden, bedarf es also einer guten Absprache hinsichtlich der Rollenverteilung für die Aufgaben.
• Je früher Fehler und Missverständnisse erkannt werden, desto effizienter lassen sie sich beheben. Dabei ist es unerheblich, wer sie mit welchem Ansatz entdeckt. Das Team sollte den Ansatz nur so wählen, dass zumindest eine Person die Chance hat, zum frühestmöglichen Zeitpunkt Alarm zu schlagen.

Hands on – Best-Practice-Beispiel

Darf's ein bisschen mehr sein? Wie und wo testen wir?

Testabdeckung und Teststufen – Best Practices

20, 50, 80 Prozent – was ist also eine sinnvolle Zielvorgabe? Alle Teststufen und wenn ja, in welchem Verhältnis? Im Sinne der Effizienz können wir auch hier Grundsätze aufstellen:

• So viel wie nötig, so wenig wie möglich. Grundsätzlich gilt: je mehr getestet, desto verlässlicher die Software. Daher ist eine höhere Testabdeckung anzustreben, die nach unserer Erfahrung jenseits der 70-Prozent-Marke liegen sollte. 100 Prozent getestete Software – und zwar bzgl. Codezeilen und fachlicher Features – sind hingegen nicht effizient. Der Aufwand ist im Gegensatz zum Outcome kaum zu rechtfertigen, der Mehrwert marginal, die Zeit schlichtweg nicht vorhanden.
• Analyse-Tools sind eine wertvolle Hilfe. Glücklicherweise gibt es eine Reihe von Programmen, die sich mit der statischen Analyse der Code-Qualität beschäftigen – sogenannte Static Application Security Testing (SAST) Tools, wie zum Beispiel das Open-Source-Werkzeug SonarQube. Diese effiziente Methode deckt Fehler und Schwachstellen automatisch auf, wobei die Regeln zur Qualitätssicherung individuell eingestellt werden können.
• Teste nur Deinen eigenen Code. Die gängigen genutzten Frameworks sind selbst gut getestet. Ob ein Apache Commons Lang: StringUtils.deleteWhitespace(myString) wirklich alle Leerzeichen löscht, bedarf keiner weiteren Abklärung. Die Druckfunktion des Betriebssystems, die durch einen Print-Befehl aufgerufen wird, muss ebenso wenig gecheckt werden.
• Klärt die Zuständigkeit! Eine klare Teststrategie hilft, Redundanzen zwischen den Teststufen zu vermeiden. Ein Integrationstest muss nicht über die Oberfläche das Zusammenspiel mehrerer Komponenten abtesten, wenn dies der Akzeptanztest ebenfalls tut. Ein Code Review durch die jeweils andere Rolle kann hier beispielsweise helfen. Klare, verbindliche Regeln der Zuständigkeiten erhöhen die Effizienz an dieser Stelle jedoch am besten.  
• Eine sinnvolle Priorisierung ist der Schlüssel zum Erfolg. Wrapper-Methoden ohne eigene Funktionalität müssen nicht getestet werden, fachlich unrealistische Edge Cases ebenso wenig. Effizient ist es aber auf jeden Fall, den Schwerpunkt der Tests auf Komponenten mit großer Komplexität und auf Features mit einer Kern-Funktionalität zu legen. Niedrigere Priorisierung bekommen Tests für nebensächliche, aber häufig vorkommende Aspekte.
• Gemeinsame Prinzipien sparen Zeit. In einem Testkonzept legt das Team fest, welche Tests konkret geschrieben werden sollen, wie mit Good und Edge Cases umgegangen wird, welche Namenskonventionen eingehalten werden. Das gemeinsame Verständnis aller Entwickler und Tester erleichtert das Arbeiten. Einmal aufgestellt, muss es nur noch von jeder umgesetzt werden, was die Effizienz des Einzelnen signifikant steigert.

Der Praxis-Check

Mittlerweile haben wir einige generelle Grundsätze in unser Testkonzept aufgenommen, um auf unterschiedlichen Ebenen effizienter zu werden. Worauf einigen wir uns aber im Hinblick auf die konkrete Umsetzung im Code? Und was davon ist nicht nur sinnvoll, sondern auch hilfreich hinsichtlich knapper Ressourcen und wenig Zeit? Um dies zu beantworten, werfen wir einen tiefen Blick in die einzelnen Teststufen.

Unittest

Unittests decken nur algorithmische Komplexität ab. Als Unittests sollte das Testkonzept nur solche Tests zulassen, die einen Algorithmus bzw. eine Berechnung abbilden. Klassen, die fester Bestandteil einer Operation sind, haben häufig einen zu geringen Kapselungsgrad für sinnvolle Tests auf dieser Stufe. Gute Unittests sorgen außerdem für eine Dokumentation komplexer Berechnungen.

Ein Negativbeispiel für einen nicht effizienten Unittest wäre das folgende. Getestet werden soll die Methode findbyId:

class CarService {
    public Optional<Car> findById(long id) {
        return carRepository.findById(id);
    }
}

Diese ist eine Wrapper-Methode der findbyId-Methode des JpaRepositorys carRepository (Hintergrund ist eine gewünschte Kapselung: Der zugehörige Controller soll nur auf die CarService-Klasse zugreifen dürfen, nicht aber auf das dazugehörige Repository selbst).

Ein möglicher Unittest in Java dazu sähe wie folgt aus:

@ExtendWith(MockitoExtension.class)
class BadUnitTest {
 
    @Mock
    CarRepository carRepository;
 
    @InjectMocks
    CarService carService;
 
    @Test
    void testFindById() {
        Car car = new Car();
        car.setId(123L);
        doReturn(Optional.of(car)).when(carRepository).findById(123L);
 
        Car foundCar = carService.findById(123L).orElseThrow();
 
        assertThat(foundCar).isEqualTo(car);
    }
}

Hier arbeiten wir mit sogenannten Mocks. Diese funktionieren wie leere Platzhalter für die Klassen CarService und CarRepository. Wir können das Verhalten dieser Klasse nun für unsere Zwecke definieren, da die Methode findById ohne diese Klassen nicht sinnvoll funktionieren würde.
 
Es gibt gleich zwei Gründe, warum dieser Unittest vermieden werden sollte:

1. Es sind eine Menge Zeilen nötig, um diese sehr simple Methode überhaupt testen zu können. Der Test selbst ist dann im Verhältnis sehr simpel und rechtfertigt den komplexen Aufbau nicht.
2. Die Methode findById ist eine Wrapper-Methode für eine JpaRepository-Methode. Es gibt in ihr weder Logik noch Algorithmus. Sie sollte also problemlos funktionieren.

Sinnvoll hingegen ist ein Unittest für folgende Methode:

public static <T, K> Predicate<T> distinctByKey(Function<? super T, K> keyExtractor, Consumer<T> duplicates){
        Set<K> seen = ConcurrentHashMap.newKeySet();
        return value -> {
            K key = keyExtractor.apply(value);
            boolean added = seen.add(key);
            if (!added){
                duplicates.accept(value);
            }
            return added;
        };
    }

Diese kurze Methode hat es in sich. Auf den ersten Blick erkennen wir nicht, was eigentlich ihr Ziel ist. Schreiben wir aber die folgenden drei Unittests, erschließt sich uns die wahre Bedeutung.

@Test
void testDistinctByKey_firstChar() throws Exception {
    assertThat(Stream.of("one", "two", "three", "four")
        .filter(StreamUtil.distinctByKey(value -> value.charAt(0))))
        .containsExactly("one", "two", "four");
}

@Test
void testDistinctByKey_length() throws Exception {
    assertThat(Stream.of("one", "two", "three", "four")
        .filter(StreamUtil.distinctByKey(String::length)))
        .containsExactly("one", "three", "four");
}

@Test
void testDistinctByKey_modulo() throws Exception {
    assertThat(IntStream.range(1, 100)
        .boxed()
        .filter(StreamUtil.distinctByKey(value -> value % 10)))
        .containsExactly(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
}

Die zu testende Methode erwartet als Parameter eine Funktion und kann auf einen Stream angewandt werden. Im ersten Test wird die Methode auf eine Abfolge von Strings aufgerufen, mit dem Unterscheidungsschlüssel "Anfangsbuchstabe". Alle Strings werden miteinander verglichen und nur solche mit unterschiedlichem Anfangsbuchstaben als Ergebnis wieder zurückgegeben. Das Ergebnis zeigt, dass distinctByKey offenbar verschiedene Objekte anhand der eingereichten Funktion unterscheidet.

Die anderen Tests funktionieren nach dem gleichen Prinzip, nur dass wir hier Objekte anhand der Länge des Strings oder des Ergebnisses bei einer modulo-Rechnung vergleichen. Was diese Tests gemeinsam haben, ist ihr einfacher Aufbau und ihre gute Lesbarkeit. Durch sie wird die sehr komplexe Methode zugänglicher und verständlicher. Zugleich ersparen wir uns mögliche Erklärungen als Kommentar im Code. Die Methode distinctByKey können wir dank der in ihr gekapselten Berechnung testen, ohne Abhängigkeiten umständlich mit Platzhaltern ersetzen zu müssen. Damit ist dies ein sinnvoller Einsatz von Unittests.

Integrationstest

Setzen wir also Unittests gezielter ein, reduziert sich logischerweise die Anzahl an getesteten Codezeilen. Für eine weiterhin hohe Testabdeckung legen wir einen größeren Fokus auf Integrationstests, die gleich mehrere Codezeilen und -blöcke auf einmal betrachten. 

In Integrationstests wird die Interaktion mehrerer (teilweise externer) Komponenten getestet. Durch die gegebenen Abhängigkeiten sind diese Tests von Natur aus etwas langsamer als Unittests. Für eventuell auftretende Performance-Probleme gibt es mittlerweile zahlreiche Lösungen, auf die an dieser Stelle aber nicht eingegangen werden soll. Vielmehr widmen wir uns wieder unserem Ziel, Tests effizienter zu gestalten. Neben dem oben bereits erwähnten Testkonzept als sinnvolle Basis gibt es verschiedene Strategien für eine gesteigerte Effizienz auf dieser Teststufe.

• Reduzierter Aufwand für den Kontext! Integrationstests erfordern häufig einen Kontext in Form von z. B. verschiedenen Objekten in der Datenbank. Hier sollte man sich als Team eine Strategie überlegen, wie dieser Kontext möglichst sinnvoll und ressourcenschonend aufgebaut wird. Grundsätzlich gibt es verschiedene Varianten:
  
  1. Objekte aufbauen und direkt in die Datenbank speichern
  Schon beim Lesen der Möglichkeiten wird klar, dass der erste Punkt jedes Mal sehr viel manuelle Arbeit von der Entwicklerin erfordert. Man hat keinen Anfangsaufwand, dafür ist aber jeder einzelne Test recht aufwändig zu schreiben.
  
  2. Hilfsmethoden für das Setup bauen
  Mithilfe der zweiten Methode kann man den permanenten Aufwand verringern. Man baut Hilfskonstrukte auf, die die Arbeit mit der Datenbank erleichtern. Dies kann zum Beispiel eine Hilfsmethode für das Abspeichern von Objekten in einer Datenbank sein, hier DatabaseInitializers genannt.

     databaseInit.company(COMPANY_ID).persist();

  Diese einzelne Codezeile baut ein Unternehmensobjekt auf, wodurch die Initialisierung des Kontexts vereinfacht und gut lesbar wird. Entwickler können sehr simpel schreiben, was sie als Voraussetzung in der Datenbank benötigen. Die dadurch entstehende Flexibilität ist durchaus ein Vorteil. Ein großer Nachteil ist der zwar einmalige, aber relativ große Aufwand zur Erstellung sowie später kontinuierlicher Wartung und Pflege, wenn sich Objekte verändern oder weitere hinzukommen.
  Ein weiterer Nachteil beider Ansätze besteht darin, dass man schnell Gefahr läuft, ein Szenario in der Datenbank zu bauen, was man durch die klassischen Operationen gar nicht abbilden kann. Dadurch testet man unter Umständen in einem fehlerhaften Kontext oder einen nicht relevanten bzw. sogar unrealistischen Fall.
  
  3. Die eigenen Operationen nutzen
  Genau hier setzt die dritte Methode an. Der Kontext wird ausschließlich mithilfe der sowieso implementierten Operationen des Systems erstellt. Der Vorteil ist, dass man wenig Anfangsaufwand hat und keine Wartung durchführen muss. Außerdem sorgt man dafür, dass der Ausgangszustand fehlerlos ist und nur mögliche Ausgangszustände darstellt, die auch durch den User später erzeugt werden können. Unrealistische Startzustände fallen also automatisch weg. Neben den vielen Vorteilen wollen wir mögliche Nachteile nicht verschweigen. Gegebenenfalls muss man gewisse Einbußen in der Flexibilität in Kauf nehmen und ist eventuell in manchen Situationen auch auf eine Manipulation einzelner Datenbankobjekte angewiesen. Eine Kommunikation mit Drittsystemen kann zudem den Kontext künstlich verkomplizieren.
  
  Effizient für den Kontextaufbau ist eine Methode, die am besten zum Projekt passt. Welche Methode nun gewählt wird, hängt stark von der Projektumgebung ab. Ein Microservice mit kleingeschnittenen Operationen wäre gut beraten, nur die eigenen Operationen zu verwenden, während ein System mit vielen Drittsystemen eher Hilfsmethoden implementieren könnte. Haben wir die effizienteste Methode gefunden, sollte sie ihren Platz im Testkonzept erhalten.
• Automatisierte Unterstützung für Assertions. Nicht nur der Kontextaufbau bietet die Chance für Verbesserungen, sondern auch der letzte Teil des Tests, in dem Erwartungen verifiziert werden. Je komplexer das zu prüfende Objekt, desto zeitaufwändiger ist es, die richtigen Assertions zu schreiben. Gerade Überprüfungen von umfangreichen Objekten können viele Ressourcen verbrauchen, da unzählige Assertions geschrieben werden müssen. Eine zeitsparende Lösung können hier automatisierte Checks dieser Objekte sein. Dies bietet zum Beispiel das Konzept des Open-Source-Projekts "Validation File Assertions" für Java. Ob und in welcher Art und Weise es genutzt wird, sollte natürlich wieder im Testkonzept festgehalten werden.

Akzeptanztest

Fazit

Effizienz in der Software-Entwicklung ist gerade bei schwierigen Rahmenbedingungen wichtig – dies gilt nicht nur für die Programmierung an sich, sondern auch für die gesamten Testaktivitäten. Sowohl bei Teamstruktur und Rollenverteilung als auch bei der technischen Umsetzung auf allen Teststufen können wir unsere Arbeit geschickt optimieren. Wir haben eine ganze Reihe von Effizienz-Grundsätzen und Best Practices aufgezählt. Wie diese in der Realität eingesetzt werden, hängt immer vom jeweiligen Projekt ab. Auch müssen nicht alle Grundsätze gleichzeitig befolgt werden. Jeder einzelne kann die Effizienz aber schon sichtbar steigern.

Autorinnen

Das könnte Sie auch interessieren