Test Driven Development

HumeSikkins

Hallo,
ich habe vor Kurzem Kent Becks : "Test Driven Development: By Example"
(http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/103-8902862-6142212?vi=glance) gelesen und muss sagen, dass mir diese Technik sehr zusagt.

Nur dummerweise weiß ich noch nicht wirklich, wie man sich das selbst beibríngen soll bzw. wie, wo und wann man damit anfangen soll.

Hat hier irgendjemand Erfahrung mit TDD? Unter C++? Was haltet ihr davon?

TDD ???
also ich kenne nur FDD.

Prof84

Hi!

Wie Du schon an einigen Posts gemerkt hast, bin ich ein Fan!
Nur dieses Buch habe ich nicht gelesen.
(Outsider: http://www.artima.com/intv/testdriven.html )

Das Erlernen ist weniger schwer, als die Disziplin den Entwicklungsprozess kontuierlich fortzuführen. Als Dino erlebe ich immer wieder Rückschläge in alte Gewohnheiten. Da ich nicht weiß, was in deinen Buch steht, kann ich Dir jetzt nichts Genaueres erzählen.

cu

P84

[ Dieser Beitrag wurde am 28.02.2003 um 19:47 Uhr von Prof84 editiert. ]

HumeSikkins

Hallo,
wie der Titel suggeriert zeigt Kent Beck in dem Buch TDD am Beispiel. Im ersten Teil geht es um ein Beispiel aus dem Finanz Bereich (multi-currency money). Im zweiten Teil entwickelt er test-first ein Testframework (xUnit).
Der letzte Teil umfasst Patterns und Techniken rund um TDD.

Ich kann seine Beispiele sehr gut nachvollziehen. Mein Problem ist nur der Übergang zum täglichen Einsatz. Es halt irgendwie schwer zu wissen, ob man es richtig macht.

was ist TDD? auf den link kann ich auch nichts drüber finden

HumeSikkins

was ist TDD? auf den link kann ich auch nichts drüber finden

Wie hast du das gemacht?

Prof84

Hört sich im wesentlichen nach dem an was ich unter M. Fowlers 'Refactoring' und 'XP planen' gelesen habe.
Mein Process ist in groben Zügen so:

OOA (Use case-, sequence (collaboration)-, Activitätsdiagramm)

OOD => Klassendiagramme,....

forward engineering => c++

A1) cppUnit Framework anpassen - http://sourceforge.net/projects/cppunit/ :
- Serialisierung der Testergebnisse in XML (Warum, haben wir hier schon ein paar Mal diskutiert )
a) Datum/ Testsuite-Name/Testcase
b) Laufzeit in msec
c) bei Error/Failure: Defaultvorgabe, Ergebnis erwartet, Ergebnis erhalten
d) Result: pass or failure
e) evt. Exception-Handling
A2) GUI für Unit-Tests schreiben oder downloaden.
A3) GUI für den Report auf XSLT Basis erstellen (ein Knaller f. Leistungsnachweis u. Kundendokumention).
A4) Testfield-Area: Sammlung aller Testsuites des Projekts in einen Programm.

Erstellen der ersten Testsuite für die Klasse, mit einer Defaultvorgabe.

Implementierungstest

Entwicklung der Klasse, Methode, ...

Regressionstest

Debug
7->8->...

Refactoring

reverse engineering Testsuite und Klasse

copy & paste Testsuite.

4-10 für nächste Klasse.
...
B1) Abstraktion und Kapselung der Default-Vorgaben (Analyse-Patterns) in UML
B2) ortogonale Entwicklung von Testsystemen und Projektentwicklung => AOP :D:D
B3) forward engineering
B4) Entwicklung einer Testsuite
B5) Serialisierung der Defaultvorgaben und Ausnahmebehandlungen in XML.

C1) Am Ende eines Tages lässt man das gesammte System durchlaufen (kann bei sehr großen Systemen 2h dauern).
C2) Am nächsten Morgen den schuldigen Entwicklern die Ohren lang ziehen und debuggen lassen.
C3) Bei collaterallen Entwicklung Testframework wieder aufziehen und der 'Stümper-Firma' zeigen, wo sie überall rumgefuscht haben.
C4) C3) Selbe auch bei Administrator Olms.
C5) C3) Oder wenn Kunden monieren, dass Du Dir wieder zu viel Stunden für zu wenig Arbeit aufgeschieben hast.
C6) Leistungsnach f. QM.

*Tääätääät*

HumeSikkins

Hallo,
ok. Erstmal schon mal danke soweit.

Ich kannte das Interview zwar schon, habe es aber trotzdem nochmal gelesen.

I recommend you sit down with somebody whose done test-driven development, so that you do it pairing with somebody who knows that style. I think you'd get a much better appreciation of how it works that way, because it is so very counter-intuitive. Unfortunately we won't have time to do something like that, but I'd love to do that with you. I can almost guarantee that you'll say, "What we're going to take that small of a step? It's not worth going such a small step." And I'll say, "Just trust me. Do these tiny steps." I've seen it so many times. I remember watching someone pair program with Kent for the first time. This guy had read up on XP and was pretty much in favor of it. He was very positive about XP already. There were times when his jaw was dropping at the tiny little moves Kent was making. He came out of it realizing that there is a whole style to test-driven development that he didn't expect.

Wie kriege ich Martin Fowler oder Kent Beck dazu mir das beizubringen?