Ein agiler Ansatz

AgileUnit: Test Valuable

Ricardo Ferreira

AgileUnit ist ein „Nischen-Test-Framework“, das komplementär zu JUnit genutzt werden kann. Die Theorie besagt, dass sich Code nach Auslieferung nicht mehr ändert und deshalb die Unit-Tests nicht mitgeliefert werden müssen. Die Praxis zeigt jedoch, dass sich Software im Lauf ihrer Lebensdauer verändert, unentdeckte Bugs kommen zum Vorschein oder Fehler werden durch die Wartung unbeabsichtigt einprogrammiert. Nicht selten werden neue Features implementiert. Sie können unentdeckte Bugs enthalten, oder die Unit-Tests werden mit heißer Nadel gestrickt. Sprich, es wird nicht alles gründlich getestet. Die Gründe dafür sind verschieden: Zeitdruck, Geldbudget, Stress usw. Hier kommt AgileUnit ins Spiel.

Das Framework testet Code kontinuierlich, aber lazy. Die Tests sind vollkommen externalisiert (über Property-Files) und bilden konfigurierbare Einheiten ohne Kompilierung des Systems. AgileUnit ist ein Hybrid, der sowohl Tester als auch Logger ist. Die Stärke von AgileUnit macht sich vor allem bei der Fehlersuche und der Maintenance bemerkbar (deshalb die Überschrift „Test Valuable“) – nicht zuletzt weil AgileUnit sowohl Requirement als auch testgetrieben ist. Bei komplexer Logik und beweiskritischen Bereichen der Software ist der Einsatz von AgileUnit empfehlenswert.

Wann soll man aUnit NICHT einsetzen?

Wann soll man aUnit NICHT einsetzen? Bei trivialen Bereichen der Software oder Bereichen, die gut durch JUnit-Tests abgedeckt wurden und auch ohne diese Tests bei Fehlern problemlos und innerhalb vernünftiger Zeit bearbeitet werden können.

Wie sieht ein Test mit aUnit aus?

Am Beispiel der Klasse Sum.java (Listing 1) soll gezeigt werden, wie der Aufruf eines Testbefehls mittels Snippets aussieht. (Hier wird das Ergebnis der Methode plus getestet).

Listing 1 – Sum.java
public int plus( int a , int b ) {
// your method logic goes here...
	int result = a + b;
TestSum.setInput( result ).test( Sum.class , "plus" );
	return result;
	}

Konfiguriert wird der Test über Property-Files wie Listing 2 gezeigt. Als fiktives Business Rule für diesen Show Case erlauben wir absichtlich keine Werte kleiner Null.

Listing 2 – TestSum.properties
#******************************************************
#  TEST: plus(int a, int b)
# *****************************************************
 user.method.name.1a=plus
# USER INTERACTION SIMULATION
user.input.value.1a=-3
user.input.value.1b=2
# REQUIREMENT'S DEFINITION
comparation.value.1a=EQUAL_OR_BIGGER
expectation.value.1a=0
# *****************************************************

Das bringt Synergien sowohl für das Requirement- als auch für das Maintenance-Team mit sich. aUnit selbst besitzt auch eine kleine, übersichtliche Property-Datei, die das Verhalten des Tests bestimmt (Listing 3).

Listing 3 – agileunit.properties
#*****************************************************
#  AgileUnit Properties
# ****************************************************
show.regulate.trace=false
show.success.trace=false
show.failure.trace=true
show.error.trace=true
skip.continuous.stop=false
#*****************************************************

Der Output eines durchgefallenen Tests ist eine einzige Zeile und hat folgende Syntax:

[FAILURE] - WHERE: WHY: REASON: TIMESTAMP: 

Beispiel eines durchgefallenen Tests:

[FAILURE] - WHERE: ch.algoritmo.example.Sum:plus() - WHY: input does NOT match the rule - REASON: input is (Integer:-1) but shall be BIGGER rule (Integer:0) - TIMESTAMP: 19,5,2011 - 11:19:12 

Oder im Erfolgsfall, falls die Properties gesetzt sind:

[REGULATE] - WHERE: RULE: 
[SUCCESS] RESULT: TIMESTAMP: 

[REGULATE] - WHERE:...Sum.plus() - RULE: output(Integer:2).shall( Be.BIGGER ).as(Integer:0) 
[SUCCESS] - RESULT: input is (Integer:2) and it is BIGGER rule (Integer:0) - TIMESTAMP: 19,5,2011 
Wie wird der eigentliche Test erstellt?

Für die Testerstellung liefert aUnit ein Plug-in mit, das sich bei Eclipse einklinkt und sowohl über die Toolbar als auch über den Class-Wizard (Ctrl+N) erreichbar ist. Genauere Details bietet die Dokumentation.

Abb. 1: Toolbar Wizard
Geschrieben von
Ricardo Ferreira
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.