TDD - Test Driven Development in der Praxis?

NetzUnity und Informatik-forum wurden zusammengelegt. Eine entsprechende Ankündigung wird demnächst noch folgen. Für 2025 ist hier einiges geplant! Bei Fragen bitte per DM an Maximilian Rupp wenden.

    Ich bin am überlegen ob wir in der Firma auf TDD umsteigen sollten. Hab diesbezüglich schon einiges drüber gelesen und in der Theorie klingt das ja alles schön und gut, aber ich hab kA wie bzw ob sich das überhaupt richtig umsetzen lässt.

    Setzt jemand von euch auf TDD (abseits von sepm oder ähnlichen LVAs)? Vor allem in Verbindung mit "klassischen" Enterprise Applications im .net (silverlight, wpf mit entity framework/open access und konsorten) würd's mich interessieren, nimm aber gerne auch jede andere Erfahrung an :)

    Wir verwenden einen TFS 2010 mit dem MSF Agile v5.0 Team Project Template, auch Erfahrungen diesbezüglich würden mich brennend interessieren. :) Prinzipiell alles was mit ALM zu tun hat ^^

    :(){ :|:&};:

    Nicht ganz die Antwort die du wahrscheinlich suchst: aber eine bessere Sichtweise bekommt man meiner Meinung nach wenn man sich den Grund hinter TDD genau durch den Kopf gehen lässt:

    • Du produzierst automatisch testbaren Code (ja - es gibt genug nicht testbaren Code - sitze gerade davor in der Firma :-P)
    • Du erreichst hohen Abdeckungsgrad
    • Du lässt dich nicht "blenden" und dir fallen vorher andere TCs ein

    Wenn du also im Hinterkopf alles ordnest lässt TDD imo auch zu, dass du zuerst ein wenig Code schreibst und dann die Tests (IntelliSense ...). Also ich überlege mir immer die TCs, schreib testbaren Code und dann die UTs. Aber TDD ist imo ein ganz kleiner Teil ... Interessanter wirds auf den Test Ebenen drüber imo

    My 5 cent
    LG

    Erstmal Danke für deine Antwort!

    Zitat

    (ja - es gibt genug nicht testbaren Code - sitze gerade davor in der Firma :-P)


    was wäre das denn etwa? Ich tu mir zumindest momentan schwer mir Tests für komplexe GUIs, EntityFramework,.... vorzustellen. Ja klar, Unit Tests für einfachen DAL und BLL sind eher leicht zu realisieren, aber macht man sich dann wirklich die Mühe die GUI mit Unit Tests zu versorgen?

    Zitat

    Interessanter wirds auf den Test Ebenen drüber imo


    Was meinst du da konkret? Bei uns läuft das atm noch eher caotisch ab (sind auch nur 3 devs und 1 testerin). Unsere Testerin "spielt" sich einfach mit den Applikationen (kaum vorher definierte testcases) und erstellt dann am TFS die Bugs. Verwendet ihr da eines der Test Frameworks, gibt da ja glaub ich auch welche die automatisierte GUI tests laufen lassen.

    :(){ :|:&};:

    Ich versuchs zu beantworten ;)

    • GUI Test = Model-View-ViewModel- dort wos nicht mehr geht mit z.B. Telerik automatisieren. Aber man schafft mit WPF/MVVM schon sehr gute regressions Testbarkeit. Einarbeitungsaufwand ist etwas hoch - am besten ein Framework nehmen (Caliburn Micro oder MVVM Light oder das neue Prism [da bin ich grade am Doku lesen]). Eben auch Tester mit Domain Knowhow für explorative Tests (siehe Agile Testing von Lisa Crispin und Janet Gregory) - das ist wahrscheinlich was eure Testerin ist / macht :)
    • Entity Framework = Repository (siehe Programming Entity Framework von Julia Lerman). Backend faken. Auch gute Stichwörter: SQL Server MS DTC, Snapshots -> da mit kann man sich gute Testumgebungen bauen.

    Was drüber passiert ist sehr komplex. Ich schreib grade Seminararbeit im INSO drüber. Aber selbst mit Grundlagen knackt man locker 60-70 Seiten.

    Prinzipiell musst du folgendes beachten:
    http://testsidestory.files.wordpress.com/2009/12/agile-test-quad2.jpg
    Du befindest dich hiermit im Q1 (links unten). Das macht der Entwickler um Contracts mit anderen Entwicklern abzuschließen (siehe xUnit Test Patterns von Gerard Meszaros). Q2-Q4 ist dann nicht mehr sooo einfach. Gibt aber einige gute Bücher - kann dir ein paar Links schicken falls dich Q2-Q4 interessiert :)

    LG

    Einmal editiert, zuletzt von damike (11. Februar 2011 um 14:14)

    Achja bzgl. untestbaren Code:
    Einfach zu viele externe Abhängigkeiten, wenig Manipulationsmöglichkeiten. Worst Case (gerade so eingefallen): du hast ne Klasse und übergibst im Konstruktor eine Web File welche sie downloaden soll. Mit "Download()" startest du dann den Download. Da hast du dann halt natürlich Probleme irgendwas zu Testen (z.B. Wie simulierst du ein Timeout? Du kannst keinen Contract mit Hilfe von Unit Tests mehr schließen -> nicht testbar).

    Guter Einstieg ist imo http://xunitpatterns.com/ hab dafür aber damals den ganzen Sommer gebraucht zum Lesen - sehr zach. Aber da steht alles drinnen (nur auf abstrakter Ebene mit Fallbeispielen in JUnit - also nicht für eine spezielle Technologie jetzt).

    LG

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden