VSTS im Einsatz: Test & Qualitätssicherung

… VSTS bietet zusätzlich die Möglichkeit,
die Einhaltung von Richtlinien schon
während der Entwicklung zu erzwingen.
Speziell über die selektiv aktivierbaren
Check-in-Policies kann sichergestellt werden,
dass z.B. nur kompilierbarer Code in
die Sourcecode-Verwaltung aufgenommen
wird, oder dass vor dem Check-in die
Änderungen mit Work Items verknüpft
werden.

Ein zunehmend wichtiger Aspekt zur
Sicherstellung der Qualität ist „Continuous
Integration“ (siehe Teil 2 dieser Artikelserie
in der Ausgabe 6.07 des dot.net
magazin
). Nach jedem Check-in wird der
Build-Prozess automatisch gestartet, die
automatisierten Tests ausgeführt und die
Ergebnisse abgespeichert. Aktuell unterstützt
VSTS dieses Feature nicht. Jedoch
kann der Build-Prozess z.B. in Form eines
„Nightly Builds“ als „Scheduled Task“
automatisch gestartet werden. Alternativ
kann ein von Microsoft frei erhältlicher
Web Service auf einem IIS installiert
werden, der die Erweiterbarkeit des TFS
ausnutzt und schon vor Erscheinen der
nächsten VSTS-Version eine Continuous
Integration ermöglicht [6].

Testen, Testen, Testen

Die Möglichkeiten, die VSTS zur Unterstützung
der Qualitätssicherung während
der Entwicklung bietet, sollten nicht dazu
verleiten, anzunehmen, dass dem Team die
ganze Arbeit abgenommen wird. Es ist noch
immer sehr wichtig, den für sich passenden
Entwicklungsprozess zu finden, die für das
aktuelle Problem optimale Strukturierung
des Codes zu definieren oder die Struktur
der Anforderungen festzulegen. Sind diese
und andere wichtige Aspekte der Entwicklung
durchdacht und festgelegt, hilft
VSTS dabei, dass diese Festlegungen nicht
im Laufe des Projektes verwässert werden
oder durch Nicht-Beachtung unerwartet
zu Projektverzögerungen führen.

Neben all den prozessbegleitenden Aspekten
der Qualitätssicherung ist und bleibt
das Testen eine sehr wichtige Aktivität, die
mit großem Aufwand verbunden ist und
eine große Sichtbarkeit hat. Das Testen soll
sicherstellen, dass die Umsetzung von Anforderungen
im Code korrekt funktioniert.
Um den größten Effekt aus dem Testen zu
ziehen, muss dies frühzeitig in der Entwicklung
beginnen und kontinuierlich zur Entwicklung
erweitert, angepasst und durchgeführt
werden. Mindestens der Stand am
Ende einer Iteration sollte getestet werden.
Besser ist das regelmäßige Testen als Teil
von Nightly Builds oder einer Continuous
Integration. Eine solche Häufigkeit von
Tests ist manuell nicht mehr beherrschbar
– deshalb ist ein hoher Automatisierungsgrad
von Tests unabdingbar.

Auch wenn die später beschriebene
Werkzeugunterstützung bei der Erstellung
automatisierter Tests und deren Verwaltung
sehr effizient ist, müssen vorher
einige Punkte bedacht und festgelegt werden.
Zum einen muss definiert werden, ab
wann automatisierte Tests erstellt werden,
um später nicht mehr Zeit in die Anpassung
der Testfälle investieren zu müssen
als in die Erstellung des Produktiv-Codes.
Auch die Strukturierung der automatisierten
Tests sollte festgelegt sein, bevor die
ersten Tests erstellt werden, damit gleich zu
Beginn einem später nicht mehr beherrschbaren
„Wildwuchs“ vorgebeugt wird. Abhängig
von der Entwicklungsart (örtlich
verteilt, lokal usw.) und der Produktstrategie
muss z.B. definiert werden, an welcher
Stelle Unit-Tests in der Sourcecode-Hierarchie
platziert werden. Eine sehr hilfreiche
Beschreibung zur Sourcecode-Strukturierung
befindet sich in der „Microsoft Team
Foundation Server Branching Guidance“
[3]. Weiterhin muss bedacht werden, welche
Teile der Software nicht automatisiert
getestet werden können und wie damit
umgegangen wird. Idealerweise ist die
automatisierte Testbarkeit schon eine Anforderung
an die Software selbst, sodass
sich manuelle Tests auf ein Minimum beschränken
lassen und deren Ausführung in
größeren Abständen erfolgen kann.

Diese Liste zu beachtender Punkte erhebt
keinerlei Anspruch auf Vollständigkeit.
Sie soll vielmehr verdeutlichen, dass
die Aktivitäten und die entsprechenden
Werkzeugunterstützungen nicht planlos
durchgeführt werden und damit zu unerwünschtem
Mehraufwand führen.

Unit-Test

Bereits sehr früh in der Entwicklung können
Unit-Tests eingesetzt werden und sind
daher als wesentliche Testart in der Developer-
Edition von VSTS integriert. Ein Unit-
Test bündelt die automatisierten Tests von
logisch zusammengehörigen Funktionen.
Im Extremfall können diese Tests sogar vor
der Implementierung geschrieben werden,
was beispielsweise im Test-Driven-Development-
Ansatz formalisiert wird. Mit
dem Einsatz von Unit-Tests soll das beabsichtigte
Verhalten von Klassen überprüft
oder sogar definiert werden. Auch wenn
eine Unit nicht notwendigerweise einer
Klasse und eine Funktion nicht unbedingt
einer Methode entspricht, ist dies der Weg,
den viele Entwicklungsumgebungen zur
Erzeugung von Unit-Tests anbieten. So
auch VSTS. Nachdem ein Testprojekt der
Solution hinzugefügt wurde, kann beispielsweise
über das Kontextmenü von
Klassen oder Methoden im Code ein Unit-
Test-Template erzeugt werden. Dazu wird
ein Wizard geöffnet, der sämtliche Klassen
und Methoden hierarchisch darstellt (Abb.
3). Aus dieser Liste lassen sich die Methoden
oder auch Eigenschaften auswählen,
für die VSTS das Gerüst eines Unit-Tests
generiert, der sofort lauffähig ist.

Abb. 3: Die Auswahl von Elementen für Unit-Tests

VSTS unterstützt den Entwickler auch
beim Testen nicht-öffentlicher Methoden
und Eigenschaften, indem zusätzlich die
Datei VSCodeGenAccessor.cs generiert
wird. Diese enthält Wrapper für den Zugriff
auf die nichtöffentlichen Elemente,
der über Reflection realisiert ist. Das Testen
nicht-öffentlicher Methoden sollte
jedoch gut überlegt werden. Während beispielsweise
das automatische Refactoring
der öffentlichen Elemente auch im Testprojekt
durchgeführt wird, muss das Refactoring
für nicht-öffentliche Elemente
im Testprojekt manuell erledigt werden. …

Kommentare

Schreibe einen Kommentar

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