• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Unit Tests – Was sollte man testen?

    von am 2. März 2009

    Eigentlich habe ich ja nicht gedacht, dass ich so schnell wieder was über Unit Tests schreibe, aber mir war gerade danach. Vor ein paar Tagen habe ich ja ein wenig aus dem Nähkästchen geplaudert, was die Einführung von Unit Tests angeht. Heute soll es darum gehen zu definieren, was man testen sollte.

    Gleich vorne weg, das Beste was man haben kann ist eine 100% Pfadabedeckung, am zweitbesten wäre eine 100% Code Coverage. Und soll ich euch was sagen: Ich glaube kein größeres PHP Projekt hat eines der beiden erreicht. Muss man aber auch gar nicht. Wenn die Kernkomponenten gut getestet sind, dann hat man schon viel gewonnen. 80-90% Codeabdeckung sind immer noch unglaublich gut.

    Nehmen wir uns aber den Standardfall vor. Wir haben ein Projekt, das es schon seit Monaten oder Jahren gibt und führen erst sehr spät die Tests ein. Problem erkannt? Im Nachhinein ist es sehr schwer eine hohe Testabdeckung zu erhalten. Sollte man aber trotzdem versuchen den alten Code abzudecken? Meiner Meinung nach ja, aber nicht sofort.

    Alter Code wird dann mit einem Test abgedeckt, wenn man ihn erweitert. Sobald man ihn anfasst und/oder refaktoriert, wird ein Test fällig. Was aber noch wichtiger ist, ist das Schreiben von Tests, sobald man einen Bug gefixed hat. Auf diese Weise kann man sicher sein, dass Fehler, die bereits behoben wurden nicht noch einmal auftreten. Solche Tests nennt man übrigens Regressionstests. Wenn man dies eine Weile beherzigt, sollte man alten Code immer besser abgedeckt haben.

    Was neuen Code angeht, da bin ich der Überzeugung, dass man alles testen sollte, was neu frisch geschrieben wurde. Ganz einfach.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    10 Kommentare »


    • Ralf Eggert
      am 2. März 2009 um 10:21 Uhr

      Wie unterscheidet sich denn eine 100%ige Pfadabdeckung von einer 100%igen Codeabdeckung? Beinhaltet das eine nicht auch das andere?

      Eine 100%ige Codeabdeckung sollte man eigentlich immer erreichen können, wenn man sich konsequent an die testgetriebene Entwicklung hält. D.h. auch wenn man einen Bug fixt, sollte man diesen nicht mal eben schnell korrigieren, sondern zuerst den entsprechenden Unittest schreiben, der den Bug nachstellt.


    • Salz`
      am 2. März 2009 um 10:52 Uhr

      Ich denke, da es zum teil auch mein Problem ist, die meisten Programmierer dürften eher Probleme haben für so manch merkwürdigen Quelltext ein Test zu schreiben, ein refactoring wäre dann zwar wünschenswert aber wahrscheinlich einfach nicht machbar.


    • Nils Langner
      am 2. März 2009 um 11:03 Uhr

      @Ralf: Juhu, ich hab ein Thema für Morgen: 100% Pfadabdeckung vs. 100% Codeabdeckung :) Und ja, du hast natürlich Recht, dass TTD hier sehr helfen kann, leider durfte ich es noch nie wirklich in einem “richtigen” Projekt erproben.

      @Salz: Du hast natürlich auch Recht. Was in der Literatur immer als bester Weg genannt wird, ist in der Realität einfach nicht immer realisierbar. Leider meistens wegen Zeitmangel.


    • Tobi
      am 2. März 2009 um 11:55 Uhr

      Mich würde mal ein kurzes Tutorial interessieren, wie du MVC basierte Webapplikationen testest. Und welche Testsuite bevorzugst du? PHPUnit, SimpleTest, etc.?

      Aus meiner Sicht ein sehr interessantes Thema, über das du ruhig mehr schreiben kannst.

      Viele Grüße
      Tobi


    • Malte
      am 2. März 2009 um 15:31 Uhr

      Kleine Anmerkung: Die Tests für den Legacy Code sind bereits _vor_ dem Refactoring oder dem Hinzufügen von neuem Code zu schreiben. Einfach um sicherzustellen, dass die alte Codebasis vom neuen Code verwendet werden kann.

      Gerade mit altem Code können einem die Unittests den Tag retten.

      Man baut kein Haus auf ein morsches Fundament. Da wird zuerst das Fundament angepackt, falls das Haus weiter benutzt oder erweitert werden soll.


    • Michael
      am 2. März 2009 um 17:30 Uhr

      Tobi: Genau das würde ich auch fragen wollen.

      “Normale Klassen” mit ein paar Methoden drin zu testen ist meistens unproblematisch. Was jedoch richtig nervig ist, “alles andere” zu testen, sprich MVC (vor allem davon das C und V).
      Da muß man dann schon mit Tools wie Selenium hantieren, und es ist nicht immer einfach, damit alles abzudecken, vor allem komplizierte Formulare, mehrseitige Formulare etc.

      Einfache Beispiele und Anleitungen gibt es [1], aber wünschenswert wären eben auch ein paar umfangreichere, praktische Beispiele, vorzugsweise mit dem Zend Framework.

      Ich kann auch nur zustimmen, häufig liegt es am engen Zeitrahmen, der ausführliches automatisiertes Testing verhindert. Laut Theorie (und später auch Praxis) ist es von Vorteil, aber bei einem halbwegs umfangreichen Projekt kostet das Erstellen von Tests schnell mehrere MT, und das will keiner bezahlen (auch wenn man erklärt, dass man dadurch später weniger Bugs (= zufriedenere Kunden) hat und Zeit einsparen wird bei der Bugsuche…)

      [1] http://www.phpunit.de/manual/3.3/en/selenium.html


    • PHP hates me - Der PHP Blog » Pfadabdeckung vs. Codeabdeckung
      am 3. März 2009 um 07:00 Uhr

      [...] ich ja in meinem gestrigen Beitrag über 100 Pfad- bzw. Codeabdeckung geredet habe, möchte ich heute doch noch mal genauer erklären, wo denn überhaupt der Unterschied [...]


    • Malte
      am 3. März 2009 um 14:25 Uhr

      @michael: Zend_Framework hat da in einer der letzten Updates einem das Leben leicht(er) gemacht, mehr schreibt Matthew Weier O’Phinney in “Setting up your Zend_Test test suites” [1]. Falls man doch lieber auf PHPUnit schielt, dazu hat Federico Cargnelutti
      auch bereits einen Ansatz im Artikel “PHPUnit: Testing Zend Framework Controllers” [2] ausgelassen.

      [1] http://weierophinney.net/matthew/archives/190-Setting-up-your-Zend_Test-test-suites.html
      [2] http://phpimpact.wordpress.com/2008/12/27/phpunit-testing-zend-framework-controllers/


    • Malte
      am 3. März 2009 um 14:27 Uhr

      Was ich auch noch sagen wollte: Wenn keine Tests geschrieben werden braucht sich auch über Tests keine Gedanken gemacht zu werden. Zur Not testet doch immer noch der Kunde, oder? Ist doch gar nicht nötig für die Betriebssicherheit von kommerzieller Software überhaupt was einzuplanen. Lass krachen, Junge!

      Aber wenn ich selber meine Bibliothek oder Anwendung entwickle, dann muss ich doch eh testen, ob die Funktioniert. Wer kann eigentlich beim coden belegen das sein Code funktioniert?


    • Unit Tests | Der ewige Anfänger
      am 18. September 2009 um 04:35 Uhr

      [...] Was sollte man testen? auf PHPhatesme [...]

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.