Microsoft Research hat vor kurzer Zeit PEX zum
freien Download veröffentlicht. Hinter diesem unscheinbaren Kürzel verbirgt sich ein
Tool das absolut genial und beeindruckend ist und klar mach, warum Microsoft ein research
center unterhält. Das Tool verspricht nichts weniger als die automatische Generierung
von Unit-Tests und den dazugehörigen Testcases um eine möglichst hohe Code-Abdeckung
zu erzielen. Detaillierte Informationen bietet das Whitepaper,
wer sich auf die schnelle einen Einblick verschaffen möchte findet einen Überblick
im Folgenden (na ja, für einen Überblick ist der Post vielleicht doch ein wenig lang
geraden, aber ich konnte mich nicht bremsen vor Begeisterung):
Darf ich vorstellen - PEX
Gegeben sei folgende Methode die getestet werden soll:
1:
public
string SimpleTest(int x1, int x2)
2: {
3:
if (x1
> x2)
4:
return
"x1
> x2";
5:
if (x1
< x2)
6:
return
"x1
< x2";
7:
else
8:
return
"x1
== x2";
9: }
Für das versierte Auge eines Entwicklers ist sofort klar, da brauchen wir 3 Testcases
um eine vollständige Code-Abdeckung zu erzielen. Mal sehen, was PEX daraus macht.
Zunächst mal muss PEX heruntergeladen und installiert sein. Dann kann man einfach
einen "Parameterized Unit Test Stub" erzeugen. Dazu in der Methode rechts klicken
und den Befehl aus dem Pex-Menü auswählen.
Im folgenden Dialog können Sie verschiedene Parameter angeben. Das wichtigste hier
ist das Testprojekt in dem der Stub erzeugt werden soll.
Der erzeugte Stub sieht dann so aus:
1:
///
<summary>
2:
///
This class contains parameterized unit tests for Calculation
3:
///
</summary>
4: [TestClass]
5: [PexClass(typeof(Calculation))]
6:
public
partial
class CalculationTest
7: {
8: [PexMethod]
9:
public
string SimpleTest(
10: [PexAssumeUnderTest]Calculation
target,
11:
int x1,
12:
int x2
13: )
14: {
15:
string result
= target.SimpleTest(x1, x2);
16:
return result;
17:
//
TODO: add assertions to method CalculationTest.SimpleTest(Calculation, Int32, Int32)
18: }
19:
20: }
Bei diesem Stub handelt es such um eine Vorlage für einen parameterisierten Unit-test.
Toll, und was lässt sich damit nun machen? Wir können eine "Exploration" starten.
Diese Exploration versucht nun Input-Parameter zu finden die zu einer möglichst 100%igen
Code-Abdeckung führen. Und hier beginnt nun die Magic von PEX. Ohne unser Zutun findet
PEX 3 Kombinationen von Input-Parametern die tatsächlich eine komplette Code-Abdeckung
erzielen- WOW! Dazu analysiert PEX wirklich den von uns erstellten Code und kann daraus
definieren, mit welchen Input-Parametern die einzelnen noch nicht abgedeckten Zweige
erreicht werden können.
Und das schönste, PEX baut uns automatisch 3 Unit-Tests die diese Testcases implementieren:
1: [TestMethod]
2: [PexGeneratedBy(typeof(CalculationTest))]
3:
public
void SimpleTest01()
4: {
5:
string s;
6: Calculation
calculation = new Calculation();
7: s
= this.SimpleTest(calculation, 1, 2);
8: Assert.AreEqual<string>("x1
< x2", s);
9: }
10:
11: [TestMethod]
12: [PexGeneratedBy(typeof(CalculationTest))]
13:
public
void SimpleTest02()
14: {
15:
string s;
16: Calculation
calculation = new Calculation();
17: s
= this.SimpleTest(calculation, 1879212556, 1879212556);
18: Assert.AreEqual<string>("x1
== x2", s);
19: }
20:
21: [TestMethod]
22: [PexGeneratedBy(typeof(CalculationTest))]
23:
public
void SimpleTest03()
24: {
25:
string s;
26: Calculation
calculation = new Calculation();
27: s
= this.SimpleTest(calculation, 256, 254);
28: Assert.AreEqual<string>("x1
> x2", s);
29: }
Diese Unit-Tests können wir nun starten und sehen, dass diese wie erwartet alle erfolgreich
sind.
Damit haben wir einen Test automatisiert erstellt, der sicherstellen kann, dass diese
Methode ihr Verhalten nach Außen für die aktuell definierten Test-Cases nicht verändert.
Damit können ungewollte Änderungen an der Methode erkannt und beseitigt werden. Ob
die Methode allerdings ihre Aufgabe korrekt erledigt, kann PEX natürlich nicht testen.
Haben wir die Funktionsweise einer Methode allerdings einmal validiert, kann PEX nun
sehr einfach dieses Verhalten prüfen. Und natürlich eignet es sich auch sehr gut um
mögliche Test-Cases zu definieren. Es müssen in diesem Fall dann nur noch die einzelnen
Ergebnisse je Test validiert werden.
Ändern wir die Methode ab, so dass sich ihr Verhalten ändert, dann alarmiert uns der
entsprechende Test.
Soweit sogut - Und was geht sonst noch?
Wenn wir nun ein gewünschte Änderung der Funktionalität implementieren, wie kann PEX
dann damit umgehen? Zunächst würden wir die vorhandenen Tests durchführen, damit wir
sicher sind, dass die aktuelle Funktionalität noch korrekt läuft. Dann erweitern wir
unsere Methode:
1:
public
string SimpleTest(int x1, int x2)
2: {
3:
if (x1
> x2 * 2)
4:
return
"x1
> x2 * 2";
5:
if (x1
> x2)
6:
return
"x1
> x2";
7:
if (x1
< x2)
8:
return
"x1
< x2";
9:
else
10:
return
"x1
== x2";
11: }
Zeile 3+4 haben wir neu hinzugefügt. Nun starten wir eine neue Exploration und
PEX ermittelt einen weiteren Test-Case um diese Funktion ebenfalls abzudecken.
Schön - darf's noch ein bisschen mehr sein?
Dieses einfache Sample war ja schon sehr beeindruckend. Die Frage, die sich aber natürlich
direkt stellt, ist wie weit geht denn das? Wir wollen nun den Schwierigkeitsgrad für
PEX schrittweise steigern. Integer-Werte sind ja noch relativ einfach zu handhaben,
aber wie sieht's denn beispielsweise mit Strings aus? Hierzu zunächst wieder eine
Methode, die wir testen wollen:
1:
public
class StringOperations
2: {
3:
public
string CheckString(string Input)
4: {
5:
if (Input.StartsWith("abc")
&& Input.Length > 10)
6:
return Input
+ " Starts with 'abc' and length > 10";
7:
if (Input.StartsWith("abc"))
8:
return Input
+ " Starts with 'abc'";
9:
if (Input.StartsWith("ABC"))
10:
return Input
+ " Starts with 'ABC'";
11:
return
"Unknown
pattern";
12: }
13: }
Stubs erzeugen und Exploration starten. Ob PEX wohl solche Operationen wie "StartsWith"
und "Length" versteht?
Es findet tatsächlich alle erforderlichen Input-Parameter und sogar noch mehr! PEX
stell fest, dass unsere Methode beim Übergeben einer NULL-Referenz eine Exception
wirft. Und damit nicht genug, PEX kann uns auch einen Vorschlag machen, wie wir unseren
Code verbessern können. Dazu im "Pex Exploration Results" - Fenster unter Views "Show
suggestions window" aufrufen.
Durch einen Doppelklick auf den Eintrag am unteren Rand des Bereichs öffnet sich ein
Fenster, das die vorgeschlagene Änderung direkt in unseren Code einfügen kann.
1:
public
string CheckString(string Input)
2: {
3:
//
<pex>
4:
if (Input
== (string)null)
5:
throw
new ArgumentNullException("Input");
6:
//
</pex>
7:
if (Input.StartsWith("abc")
&& Input.Length > 10)
8:
return Input
+ " Starts with 'abc' and length > 10";
9:
if (Input.StartsWith("abc"))
10:
return Input
+ " Starts with 'abc'";
11:
if (Input.StartsWith("ABC"))
12:
return Input
+ " Starts with 'ABC'";
13:
return
"Unknown
pattern";
14: }
Die Zeilen 3-6 wurden von PEX erzeugt. Natürlich können wir das entsprechende Verhalten
im Code direkt ändern und an unsere Vorstellungen anpassen. Vielleicht ist es aber
gar keine schlechte Idee, in diesem Fall eine Exception zu werden. Dies ist das Standard-Verhalten
von PEX an dieser Stelle. Wird die erwartete Exception nicht mehr geworfen oder eine
andere Exception tritt auf, wird dies durch einen fehlgeschlagenen Test angezeigt.
Der nächste bitte!
So nun wollen wir noch einen Schritt weitergehen und sehen, wie PEX mit Listen umgehen
kann. Dazu habe ich folgende Testmethode erstellt (über den Sinn einer solchen Methode
wollen wir jetzt nicht nachdenken)
1:
int result
= 0;
2:
if (list.Count
> 10)
3: {
4:
foreach (int i in list)
5: result
+= i;
6: }
7:
else
8: {
9:
foreach (int i in list)
10: result
*= i;
11: }
12:
return result;
Die Methode bekommt eine Liste von Integer-Werten übergeben. Wenn es mehr als 10 Elemente
sind, werden diese addiert, sonst werden die Werte miteinander Multipliziert. Mal
sehen, wie PEX mit Listen umgeht.
PEX erkennt noch, dass unsere Methode mit Null-References nicht korrekt umgeht, aber
dann verließen sie ihn. Aber freundlicherweise bekommen wir noch einen Hinweis
"2 Object Creations". klickt man darauf, dann bekommt man schon mehr Informationen.
Aha, PEX kann also eine List<int> nicht erzeugen. Also was tun? Klickt man den
unteren der beiden Einträge an, bietet PEX etwas weiter rechts die Möglichkeit eine
Factory zu definieren. Eine Factory ist ein Extensibility-Point mit dem PEX beigebracht
werden kann mit solchen Objekten umzugehen. Ein Beispiel für eine solche Factory kann
so aussehen:
1:
namespace System.Collections.Generic
2: {
3: [PexFactoryClass]
4:
public
partial
class ListFactory
5: {
6: [PexFactoryMethod(typeof(List<int>))]
7:
public
static List<int>
Create(int i)
8: {
9:
if (i
> 100)
10: i
= 100;
11: List<int>
l = new List<int>();
12:
for (int j
= 0; j < i; j++)
13: {
14: l.Add(j
* 10);
15: }
16:
return l;
17: }
18: }
19: }
Hier teilt man PEX nun mit, welche Elemente es damit erzeugen kann (Zeile 6). Anschließend
implementiert man eine Create-Methode die beliebige Parameter übernehmen kann. In
Abhängigkeit dieser Parameter wird nun eine Instanz des gewünschten Objektes erzeugt.
In unserem Beispiel übernehmen wir nur einen Parameter der die Länge der Liste angibt.
In den Zeilen 9/10 begrenzen wir die Länge der Lsite auf 100 Elemente. Die Liste selbst
befüllen wir mit einer Reihe von Zahlen. Hier ist es sicher keine gute Idee, z.B.
Zufallszahlen zu verwenden, da diese ja bei jedem Testdurchlauf andere Werte liefern
und deshalb der Assert nicht erfolgreich ausgeführt werden kann.
Mit hilfe dieser Factory kannPEX nun unsere Testcases definieren. Dazu ermittelt es
einfach geeignete Parameter für die Create-Methode in unserer Factory statt das Objekt
selbst zu erzeugen.
Die erzeugten Tests sehen dann so aus:
1: [TestMethod]
2: [PexGeneratedBy(typeof(ListCalculationTest))]
3:
public
void SumList03()
4: {
5: List<int>
list;
6:
int i;
7: list
= ListFactory.Create(2);
8: ListCalculation
listCalculation = new ListCalculation();
9: i
= this.SumList(listCalculation, list);
10: Assert.AreEqual<int>(0,
i);
11: }
12:
13: [TestMethod]
14: [PexGeneratedBy(typeof(ListCalculationTest))]
15:
public
void SumList04()
16: {
17: List<int>
list;
18:
int i;
19: list
= ListFactory.Create(536870912);
20: ListCalculation
listCalculation = new ListCalculation();
21: i
= this.SumList(listCalculation, list);
22: Assert.AreEqual<int>(49500,
i);
23: }
Nun folgt noch die Kür
Nach den Erfahrungen mit der Liste bereits etwas skeptischer geworden, wollen wir's
jetzt aber doch wissen. Wie sieht's mit eigenen Objekten aus? Wie weit kommt PEX damit?
Auch hier gibt es wieder eine einfache Methode die wir testen wollen:
1:
public
class ComplexDataCalculation
2: {
3:
public
string DoComplexDataCalculation(cData
d)
4: {
5:
if (!d.IsValid)
6:
return
"NotValid";
7:
8:
if (d.DataValues.x1
> d.DataValues.x2)
9:
return
"x1
> x2";
10:
if (d.DataValues.x1
< d.DataValues.x2)
11:
return
"x1
< x2";
12:
else
13:
return
"x1
== x2";
14:
15: }
16: }
17:
18:
public
class cData
19: {
20:
public cDataValues
DataValues { get; set; }
21:
public
string ObsoleteParameter
{ get; set; }
22:
public
bool IsValid
{ get; set; }
23: }
24:
25:
public
class cDataValues
26: {
27:
public
int x1
{ get; set; }
28:
public
int x2
{ get; set; }
29: }
Die Methode bekommt einen komplexen Datentyp übergeben. Und was macht PEX???
PEX erkennt nicht nur, dass wir zwei Null-Exceptions abfangen sollten, sondern kann
auch unser Datenobjekt so initialisieren, dass wir wieder eine 100% Codeabdeckung
bekommen. Die Unit-Tests sehen ungefähr so aus:
1: [TestMethod]
2: [PexGeneratedBy(typeof(ComplexDataCalculationTest))]
3:
public
void DoComplexDataCalculation04()
4: {
5: cDataValues
cDataValues;
6: cData
cData;
7:
string s;
8: cDataValues
= new cDataValues();
9: cDataValues.x1
= 3;
10: cDataValues.x2
= 4;
11: cData
= new cData();
12: cData.DataValues
= cDataValues;
13: cData.ObsoleteParameter
= "";
14: cData.IsValid
= true;
15: ComplexDataCalculation
complexDataCalculation = new ComplexDataCalculation();
16: s
= this.DoComplexDataCalculation(complexDataCalculation,
cData);
17: Assert.AreEqual<string>("x1
< x2", s);
18: }
Das ist schon extrem beeindruckend, wie PEX tatsächlich eine entsprechende Instanz
unseres Datenobjektes erzeugt und initialisiert und das so, dass wir alle Testcases
abdecken. Wirklich beeindruckend.
Was haltet ihr davon? Würde mich über Feedback freuen.
