Best Practises

zurück zur Hauptseite

Quality Rules and Guidelines

File system conventions

Es muss durch das AC festgelegt werden, ob eine maximale relative Pfadlänge definiert werden sollte, da unter Windows einige Programme (inkl. git) Probleme mit einer absoluten Pfadlänge > 256 Zeichen haben. Dies kann notwendig sein, da die zu erstellende Software auch auf älteren Systemen lauffähig sein muss. Zumindest sollte dieser Punkt im Rahmen zukünftiger Beauftragungen dediziert im jeweiligen Projektkontext betrachtet und ggf. auf Grundlage der Beauftragung bewertet werden.

Unit Tests

Unit-Tests oder Komponententests werden verwendet um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h. sie auf korrekte Funktionalität zu prüfen. Da Algorithmen auf Unit-Ebene meist nur eine begrenzte Komplexität aufweisen und über klar definierte Schnittstellen aktiviert werden, können sie mit relativ wenigen Testfällen weitgehend vollständig getestet werden. Dies gilt als Voraussetzung für die anschließende Teststufe „Integrationstest“. Dort werden die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausgerichtet. Damit lassen sich die modulspezifischen Detailkonstellationen auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle drastisch reduziert.

Im Rahmen der Best Practices werden zur Durchführung von Unit-Tests entwicklungsspezifische Werkzeuge wie z.B. „JUnit“ empfohlen. Die damit generierten Testfälle sind selbst überprüfend und damit wiederholbar. Eine gute Test-Unit zeichnet sich dadurch aus, dass sie möglichst wenige Abhängigkeiten zum Rest des Systems hat und damit für sich genommen gut und einfach testbar ist. Zum Test komplexerer Zusammenhänge sollte zusätzlich ein Mocking-Framework wie z.B. „Mockito“ zur Abbildung weiterer Abhängigkeiten außerhalb des eigentlichen Unit-Kontextes verwendet werden. Ein derartiges Mocking-Framework bietet dem Entwickler die Möglichkeit, das Verhalten des zu testenden Systems verifizieren können, ohne im Vorfeld Annahmen treffen zu müssen. Nebenwirkungen von anderen Klassen und/oder Systemen werden weitestgehend eliminiert und die oft kritisierte enge Kopplung von Unit-Tests an den getesteten Code reduziert. Für die Überprüfung der Code Coverage wird basierend auf den bestehenden Erfahrungen im Java-Umfeld aktuell „JaCoCo“ empfohlen.

Code Coverage

„JaCoCo“ ist ein Open-Source-Toolkit, mit dem die Qualität des Java-Codes bewertet und das Ergebnis publiziert werden kann. „JaCoCo“ wird unter den Bedingungen der „Eclipse Public License“ vertrieben und kann zudem in SonarQube eingebunden werden.

Statement Coverage – Anweisungsabdeckung

Die „Statement Coverage“ entspricht den beim Test durchlaufenden Anweisungen im Verhältnis zu allen Anweisungen. Beispiele für Anweisungen wären Wertezuweisungen bei Variablen, Fallunterscheidungen, Schleifen und Methodenaufrufe.

Branch Coverage – Zweigabdeckung

Ein stärkerer Abdeckungsgrad ist die „Branch Coverage“. Sie entspricht dem Verhältnis der beim Test durchlaufenen Zweige (auch Kanten genannt).

Condition Coverage – Bedingungsabdeckung

Die „Branch Coverage“ unterscheidet nicht, aufgrund welche Teilbedingungen eine Bedingung als wahr oder falsch ausgewertet wird. Dies erreicht die „Condition Coverage“. Man unterscheidet dabei zwischen der Einfach- und der Mehrfachbedingungsabdeckung.