Pretty Objects hat Visual T# in der Version 3.0 veröffentlicht. Zeit, dieses Tool einmal näher anzuschauen.
Die Installation erfolgt über ein Setup und muss hier wohl nicht weiter beschrieben werden.
Ich starte das Ganze mit einem kleinen Vergleich zwischen dem Testing Framework von Microsoft und Visual T# an einem einfachen Beispiel. Dieses Beispiel hatte ich vor einiger Zeit erstellt, um NUnit vorzustellen.
Die zu testende Bibliothek
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| namespace Calculator
{
public class Calc
{
public byte Add (byte b1, byte b2 )
{
int res = b1 + b2 ;
if (res > Byte.MaxValue)
{
throw new OverflowException ();
}
return (byte)res ;
}
}
} |
Die Funktion beinhaltet bereits die Überlauf-Absicherung für den zweiten Test, ansonsten nicht viel spannendes an diesem Code…
Erster Test mit Microsoft Test Framework
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| namespace CalculatorMSTest
{
[TestClass ]
public class CalcTest
{
[TestMethod ]
public void AddTest ()
{
Calc calc = new Calc ();
byte sum = calc .Add(12, 26);
Assert .AreEqual(38, sum );
}
}
} |
Auch hier gibt es nicht viel spannendes: Initialisierung (Zeile 9), Ausführung (Zeile 11) und Validierung (Zeile 13) wie wahrscheinlich schon tausend mal gesehen.
Der erste Test mit T#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| namespace CalculatorTSharp
{
testclass CalculatorTest for Calc
{
test Add( byte, byte )
{
Calc calc = new Calc();
runtest byte sum = calc.Add(12, 26);
assert sum == 38;
}
}
} |
Auf den ersten Blick könnte man meinen, es sei auch normaler C#-Code, aber auf den zweiten Blick fallen dann die Unterschiede auf:
- testclass anstelle von class (Zeile 4)
Mit dem Keyword testclass wird angegeben, dass es sich um eine Klasse für Tests handelt.
- test als Bezeichner für Testmethode (Zeile 6)
Das Keyword test bezeichnet eine Testmethode. Mit dem nachfolgenden Add(byte, byte) kann angegeben werden, welche Methode mit diesem Test überprüft werden soll. Dies ist aber optional.
- Deklarierung des Stimuli mit runtest (Zeile 10)
Die Anweisung, mit welcher der Stimuli des Tests ausgelöst wird, wird mit runtest bezeichnet. Somit ist klar ersichtlich, was Initialisierung und was Ausführung der Tests ist.
- Überprüfung mit Keyword assert. (Zeile 12)
Für die Überprüfung gibt es das Keyword assert und nicht ein Objekt wie in den bekannten Testing Frameworks
- keine Attribute
Da T# extra für Tests entwickelt wurde sind keine zusätzlichen Attribute nötig (siehe auch Punkt 1).
Eine etwas andere Syntax aber keine spektakulären Neuerungen. Ein paar eingesparte Attribute, sonst etwa der gleiche Aufwand. Bisher also kein richtiger Grund, eine neue Syntax zu lernen.
Schauen wir und noch einen zweiten Test an:
Zweiter Test mit Microsoft Test Framework
1
2
3
4
5
6
7
| [TestMethod, ExpectedException (typeof(System.OverflowException))]
public void BigAddTest ()
{
Calc calc = new Calc ();
calc .Add(150, 230);
} |
Der zweite Test validiert die Überlauf-Prüfung. Die erwartete Ausnahme wird als Attribut (Zeile 1) angegeben.
Der zweite Test mit T#
1
2
3
4
5
6
7
8
| test Add( byte a, byte b)
{
Calc calc = new Calc();
runtest calc.Add(150, 230);
assert thrown System.OverflowException;
} |
Der wichtigste Unterschied betrifft die Ausnahme. Bei T# wird das Auftreten der Ausnahme ebenfalls mit einem assert Befehl validiert. Der Test folgt somit dem bekannten Schema Initialisierung (Zeile 3), Ausführung (Zeile 5) und Validierung (Zeile 7).
In diesem Beispiel haben wir aus meiner Sicht einen Mehrwert mit T#: Das Schema wird beibehalten, während bei Tests mit dem Microsoft Test Framework die Validierung in ein Attribut an den Anfang des Tests geschoben wird.
Ausblick:
T# bietet noch weitere Vorteile, die ich in einem weiteren Artikel noch beleuchten möchte.
I proudly present to you the sixth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.
