Test Driven Development

[fanderlf]

Hoi hoi,

Kennt jemand ein gutes Buch über Test Driven Development? Auf Amazon.de finde ich nur die Bücher

Test Driven Development. By Example (Addison-Wesley Signature)
Test-Driven Development in Microsoft .NET (Microsoft Professional)

Ist eines davon noch up to date oder gibts evtl. was ganz anderes?

Finde das Thema sehr spannend

Vielen Dank schon mal!!!

Gruß
Florian

[gfoidl]

Hallo Florian,

die besten Bücher dazu sind bei Amazon schon vergriffen

Ich finde aber dass es nicht notwendig ist darüber ein Buch zu lesen* denn die Paradigmen von TDD sind einfach:

1. schreibe den Testcode
2. mache in kompilierbar
3. state den Test und lasse ihn fehlschlagen
4. setze nur die Anforderung um, damit der Test abgedeckt ist
5. starte den Test und prüfe ob der Test erfolgreich ist
6. refactore den Code zur besseren Überschichtlichkeit und Vermeidung von Redundanzen
7. starte von vorne mit dem nächsten Test

Es ist also nur Kreativität gefragt wie das umgesetzt wird. Ein Buch kann auch nicht mehr als Beispiele liefern.

Dennoch finde ich den einführenden Artikel Test-Driven Development in .NET empfehlenswert.

Voraussetzung für TDD ist dass die Umgangsweise mit einem Test-Framework gekonnt wird. Ich verwendet dafür NUnit und das einführende Beispiel dort ist schon ein Schritt in die richtige Richtung, obwohl explizit angemerkt ist dass dieses Beispiel für TDD nicht optimal ist.

* es kommt natürlich auf die Natur des Individuums an (ich brauche keins dafür).

Anmerkung: TDD ist (auch) kein Allheilsmittel - nur ein (weiteres) Paradigma der Softwareentwicklung. Wichtig ist und bleibt Disziplin!

mfG Gü

[Ralf Jansen]

Ich habe 'Test Driven Development. By Example'.

Wenn man bereits mit Unittesting halbwegs vertraut ist gibt es einen netten Überblick was den die nächsten Schritte wären um dies in einen Process zu gießen. Bleibt dabei aber bei jedem Teilaspekt absolut oberflächlich. Ist daher ganz gut dafür geeignet sich das mal unters Kopfkissen zu legen um ein Gefühl dafür zu bekommen worum es eigentlich geht. Also Nachschlagewerk oder gar als echte Anleitung aus Ausfall.

[fanderlf]

Prinzipiell ist mir klar wie TDD funktioniert - also der Ablauf. Mein Problem ist eher:

Was teste ich? Wie fange ich mit TDD überhaupt an einem konkreten Problem an?

z.B. hatte ich heute in der Arbeit mal versucht mit TDD anzufangen. Dann kam ich zu den ersten ganz einfachen Properties... schreibt man zu ganz einfachen Properties nun auch Tests?

z.B. so etwas in der Art:

[highlight=c#]
public class Person
{
private String _vorname;
public String Vorname
{
get { return _vorname; }
set { _vorname = value; }
}
}

public class PersonTests
{
[TestMethod]
public void CanSetVorname()
{
Person p = new Person();
String vorname = "Testvorname";

p.Vorname = vorname;

Assert.AreEqual(p.Vorname, vorname);
}
}
[/highlight]

Ich mein prinzipiell ist es mit Sicherheit nicht schlecht so etwas zu testen... aber ist das so die "richtige" Vorgehensweise? Bin ich da zu speziell? Oder fange ich eher mit einer Testprozedur an die beschreibt was die Klasse machen soll um dann später erst drauf zu stoßen welche Properties ich denn nun wirklich brauche?
Da hängts bei mir irgendwie Wie setze ich die Vorstellungen die ich von einer Klasse habe mit TDD um.

Ansonsten werd ich mir auf jeden Fall mal ein Buch über UnitTests zu Gemüte führen. Habe The art of unit testing hier vor mir liegen. Eventuell weiss ich ja schon genug wenn ich da durch bin.

[gfoidl]

So einfache Sachen wei Eigenschaften die nur ein Feld lesen/schreiben würde ich mir beim Test schenken.

Beispiel: Es soll eine Methode für die Summe erstellt werden.

Code erstellen der kompilierbar ist.
[highlight=c#]
public int Summe(int a, int b)
{
thow new NotImplementedException();
}
[/highlight]

Test würde fehlschlagen -> Code solange anpassen bis er die Tests besteht (hier kann auch PEX verwendet werden, denn das erstellt so gesch.... Eingaben auf die man selbst nicht kommen würde - zB dass bei einer Summe die in Overflow resultieren würde der System.Int32 einfach bein System.Int32.MinValue wieder beginnt, usw.)

Für Klassen gehts das analog. Die Klasse soweit implementieren dass die Schnittstelle nach außen steht (alle Methode sind mit den entsprechenden Signaturen vorhanden) und dann für jede Methode (und komplexere Eigenschaft, Indexer, ...) ein/mehrere Tests erstellt.

mfG Gü

[fanderlf]

OK... also eher nur Tests für die funktionalen Aspekte einer Klasse. Events würde man mit Mocks testen, oder?
Also ich kann zumindest testen ob, wenn ich eine bestimmte Property ändere (beim INotifyPropertyChanged Event) die Funktion aufgerufen wird die das PropertyChanged Event auslöst.

[gfoidl]

So ist es.


mfG Gü

[macap]

Hi,

auch wenn das Posting hier schon alt ist...

Wie bereits gesagt wurde benötigt man dafür eigentlich kein Buch.
Falls doch kann ich "Softwaretests mit JUnit" von Johannes Link SEHR empfehlen.

Ist zwar mit Java geschrieben, aber C# ist ja bekanntlich sehr ähnlich.
Außerdem ist es eine ganz nette Zusatzaufgabe JUnit-Beispielcode für NUnit und C# lauffähig zu machen ;-)


Als kurzer Anriss...

In dem Buch wird Kapitel für Kapitel ein einziges Praxisbeispiel durchgezogen.
Nämlich die Entwicklung eines Wörterbuchs.

Hierbei wird streng nach dem Test-First Ansatz vorgegangen.
D.h. wie bereits erwähnt werden erst Testcases erzeugt und Dummy-Methoden, die NotImplementedExceptions werfen.
In mehreren Iterationen wird dann anschließend Kapitel für Kapitel das Wörterbuch-Programm um weitere Funktionen erweitert.


Bye,
Martin

[gfoidl]

Hallo,

danke für die ergänzende Info.

Hier noch ein Link für das Buch von Link


mfG Gü

[fanderlf]

Ich habe mir auch noch ein nettes Buch zu dem Thema zugelegt. Behandelt zwar nicht konkret .NET, aber ich denke das ist bei dem Thema auch zweitrangig:

Testgetriebene-Entwicklung-mit-JUnit-FIT