Archiv der Kategorie: unittest

Von phpUnit zu Codeception wechseln

Codeception-LogoWenn du vom klassischen phpUnit zu Codeception wechseln möchtest, musst du erschreckend wenige Sachen beachten. Dafür bekommst du am Ende dann die vielen Vorteile von Codeception. Ob sich das für dich und dein Projekt lohnt, musst du latürnich (sic!) selbst für dich und dein Projekt entscheiden. Mir fiel die Wahl leicht…

Wie ich schon sagte, es braucht erschreckend wenig, damit Codeception die Tests übernimmt, da sich der „unit“ Teil nicht sooo stark von phpUnit unterscheidet. Ganz im Gegenteil ruft Codeception auch phpUnit unter der Haube auf. Du hast nur den Vorteil einer einheitlichen Test-Strategie und -Sprache und musst nicht eine Vielzahl von Dialekten behalten (phpUnit, Selenium, wtf, …).

Ich nehme mal an, dass deine unit-tests bereits funktionieren und dass diese im verzeichnis „tests“ liegen. Falls nicht, das „tests“ Verzeichnis solltest du schnell mal anlegen und deine Tests von dort aus starten 😉 Dann wird’s leichter.

Also los, die ersten Erfolge sind schnell gemacht:

  • Codeception „installieren“
    Sprich, die „codecept.phar“ ins root deines Projektes kopieren.
  • Per Konsole (phpStorm hat die ja eingebaut, sehr praktisch)
    „php codecept.phar bootstrap“
    Nun werden Grundlegende Sachen im Verzeichnis „tests“ angelegt.
  • Kopiere deine alten tests mit einer Sinnvollen Verzeichnisstruktur in das Verzeichnis „tests/unit“
  • benötigte Datenbank-Dumps kommen erstmal in „tests/_data/dump.sql“
  • Deine „tests/unit.suite.yml“ sollte in etwa so aussehen:
    class_name: CodeGuy
    modules:
     enabled: [Unit, CodeHelper, Db]
     config:
      Db:
       populate: true
       cleanup: false
  • In der „codecept.yml“ trägst du die Datenbankzugangsdaten für die tests ein, dann brauchst du die nicht in der „unit.suite.yml“ eintragen und die gelten somit codeception-weit, was später die Function- und Acceptance-Tests vereinfacht.
  • In deinen Tests musst du nun noch folgende Anpassungen machen, damit alles reibungslos funktioniert:
    • Die Testdatei fängt immer mit
      use Codeception\Util\Stub;

      an.

    • Die Tests erweitern nun
      \Codeception\TestCase\Test

      also

      class myWhateverTest extends \Codeception\TestCase\Test {
       // ...
      }
    • Die Methoden „setUp()“ und „tearDown()“ werden zu „_before()“ und „_after()“. Denkt auch an den Aufruf parent::_before() und parent::_after() in den Methoden!
  • Eure bisherige „bootstrap.php“ muss in „tests/_bootstrap.php“ oder ihr passt die „codecept.yml“ einfach an.

Damit steht nun das Grundgerüst und ihr könnt via

php codecept.phar run

eure Tests ausführen.

In meinem konkreten Fall konnte ich damit die Tests einer ZF1 Application mit Anlegen und Füllen einer Testdatenbank (MySQL) um den Faktor 8 beschleunigen. Zusätzlich kann nun recht einfach neue Tests in Codeception einfügen und die Ergebnisse stehen mir ebenfalls für Jenkins und Co zur Verfügung, teilweise mit sehr viel höherer Aussagekraft.

Viel Erfolg…

Rezension: Softwarequalität in PHP-Projekten von Sebastian Bergmann und Stefan Priebsch, 2. Auflage

Man kann sich viele Bücher zum Thema Qualitätsverbesserung in IT-Projekten zulegen, manchmal kann man während der Lektüre sogar was lernen, in den wenigsten Fällen hat man es dabei mit konkreten Programmiersprachen zu tun und noch viel weniger sind in Deutsch.
Da scheint es ein wahrer Lichtblick zu sein, dass zwei der bekanntesten PHP-Experten das Standardwerk zur Qualitätsverbesserung und -sicherung noch einmal überarbeitet haben, teilweise sogar neu geschrieben haben. Herausgekommen ist ein absolutes „must-have“.

Sebastian Bergmann und Stefan Priebsch beschreiben auf circa 460 Seiten, worauf der Qualitätsbewusste PHP-Entwickler achten muss und soll. Angefangen vom „Was ist denn eigentlich Qualität und wie kann man diese Messen?“ über „und warum ist das wichtig?“ bis hin zum „Wie sag ich’s meinem Kunden“ schreiben beide in einem lockeren Stil über eines der komplexesten Themen innerhalb des Programmieralltags.

„Softwarequalität in PHP-Projekten“ ist sicherlich kein Buch zum einfachen „runter lesen“, sondern man ertappt sich öfters dabei, eine Seite nun das x-te mal gelesen und dann doch noch das Gefühl zu haben, etwas nicht richtig verstanden zu haben. Kleiner Tip: Hier hilft es sehr, die Beispiele wirklich abzutippen und das Thema mal auszuprobieren. Frei nach dem Motto „Probieren geht über Studieren“ lösen sich dann die Fragen meist in Erkenntnis auf.

Schön zu lesen sind auch die Fallbeispiele von Typo3, Zend Framework und allen weiteren. Auch die „großen“ machen Fehler und manche lassen sich hier nachlesen. Das schöne Gefühl von „die konnten es auch nicht sofort“ stellt sich ein und lässt einen etwas beruhigter zurück.

Meine Favoriten waren die Kapitel über „Legacy Code“, „Kontinuierliche Integration“ und „Bad Practices“. Ich persönlich fand ich den präsentierten Legacy Code zwar nicht legacy genug, aber das liegt sicherlich auch an mir und meinem Background. Übertragbar sind trotzdem viele der Wege und Tips auf (noch viel) älteren Code – alles schon ausprobiert 😀

Will man nun was negatives finden, man könnte anbringen, dass die Beispiele in sich manchmal nicht konsistent sind oder der eigentlich Kern, was Bergmann und Priebsch sagen wollen, nicht immer anhand der Beispiele ersichtlich wird. Hier und da hätten die Beispiele kürzer, dafür mehr auf den Kern reduziert sein können, es hätte zu etwas schnelleren „Aha!“-Momenten geführt. Aber das wäre jammern auf einem sehr hohen Niveau. Dieses Buch richtet sich definitiv nicht an Einsteiger, die sich an solchen Dingen stören würden; es richtet sich vor allem an Profis oder interessierte Fortgeschrittene, die sich noch weiter verbessern wollen, noch näher an den „perfekten Code“ kommen wollen. Und dieses Wissen zu vermitteln schafft dieses Buch locker.

Mein Tip: Kaufen, Lesen, Verstehen (nicht auswendig lernen). Ich habe selten so ein gutes (Fach-)Buch gelesen! Wenn ihr nur wenig Budget zur Verfügung habt, euch aber die Qualität eures Codes (und eures Handwerks) nicht egal ist, dann kauft dieses Buch. Ihr werdet sehr lange Lesefreude daran haben und euer Code wird es euch danken.

tl;dr: Unbedingt kaufen und verinnerlichen

XDebug Logo

XDebug und Zend Server CE für Unit Tests und Code Coverage Reports

Wer Unit Testing betreibt, der will auch Code Coverage, ganz klare Sache. Für Code Coverage benötigt man in Verbindung mit phpUnit XDebug. In der Regel kein Problem.

Wer allerdings den ZendServer benutzt der war bisher angeschmiert, den XDebug im ZendServer zu konfigurieren kann nervig sein und eine falsch eingetragene Zeile kann den Betrieb des ZendServers sogar komplett lahmlegen.

Aber natürlich gibt es einen Weg, XDebug, ZendServer inkl. ZendDebugger laufen zu lassen, du bekommst also den ZendDebugger zum debuggen und XDebug zum Unit Testen deiner Anwendung, das beste aus beiden Welten – unter Windows 😉

Bereit? Los geht’s:

  1. ZendServer stoppen, entweder per Dienstkonsole oder mit „Apache Service Monitor“
  2. Lade dir die fehlende XDebug dll bei XDebug.org runter.
    Welche ist die passende?
    Zunächst erstmal die PHP Version deines ZendServers, dann den Link OHNE „TS“ und den mit 32-Bit, der sollte passen – war bisher bei allen meinen ZendServer-Installationen so.
    Beispiel mit PHP 5.4: „PHP 5.4 VC9 (32 bit)“
  3. Die .dll legst du nun im Verzeichnis
    /ZendServer/lib/phpext

    deines ZendServers ab.

  4. Nun ab in die php.ini
    Dort trägst du ziemlich weit unten aber ÜBER diesem Eintrag:

    zend_extension="C:\zend\ZendServer\lib\ZendExtensionManager.dll"

    (Pfad ist bei dir zumindest ähnlich)
    das hier ein:

    zend_extension="C:\zend\ZendServer\lib\phpext\php_xdebug-2.2.2-5.4-vc9-nts.dll"

    Natürlich ersetzt du den konkreten Namen durch deinen, bei mir ist das der ZendServer mit PHP 5.4 in der zum Veröffentlichungszeitpunkt aktuellsten Version von XDebug.

  5. Spaß mit Code Coverage!
    Ja, genau, schon fertig.

Ab nun kannst du Code Coverage Reports bekommen.

Was nicht geht: Du kannst mit XDebug (höchstwahrscheinlich) nicht wirklich debuggen – aber du hast ja den Zend Debugger, der zumindest mit dem Zend Studio wesentlich besser funktioniert.

Ich selbst habe bisher keine verlässlich funktionierende Konfiguration gefunden, mit dem ich via XDebug im Zend Server debuggen und profilieren konnte; mir reicht XDebug zum erzeugen der Code Coverages.

Vielen Dank geht an „Limespacer“ für diesen Beitrag, der mir dabei sehr geholfen hat:
http://www.limespace.de/2009/07/15/zend-server-ce-mit-xdebug/

P.S. Bei mir geht es auch mit aktiviertem Zend Debugger, falls das bei dir nicht der Fall sein sollte, dann schalte diesen wie im verlinkten Beitrag gezeigt einfach ab.

Unit Testing in C# mit Visual Studio 2010 Express und NUnit

Privat erstelle ich meine Projekte seit neuestem mit C#. Da ich ein Windows Phone mein eigen nenne und da irgendwann auch mal gern eine App für schreiben möchte, dachte ich, es wäre ganz gut, sich da mal wieder auf den neuesten Stand zu bringen und wieder aktiv in dieser Sprache zu programmieren. Denn nur, wenn du C# codest, lernst du C#. Gut und schön und mein aktives Projekt komplett neu in C# geschrieben. Es ist zwar noch nicht fertig, aber schon überkommt mich ein beklemmendes Gefühl. Es fehlt was. Nur was?

Nach kurzem Nachdenken wird mir klar: Ein neues PHP-Projekt würde ich ganz anders starten. Ich würde Tests schreiben. Na klar, meinem C#-Projekt fehlt das Unit Testing.

Nach kurzer Suche wird mir ganz anders: C# zu unit-testen geht zwar, aber nicht mit Visual C# Express 2010 … aber genau diese kostenlose IDE setze ich doch ein! Aber wie ich immer so schön zu sagen pflege: Geht nicht, gibt’s nicht (kost‘ nur mehr #hehe).

Nach ein paar Stunden rumfummeln und vielen anderen Einträgen folgt hier meine Schritt-für-Schritt anleitung zum Unit Testen mit C# mit Visual C# Express 2010 mit Mausklick (aber ohne Sahne 😉 ):

  1. Visual C# Express 2010 muss installiert sein, idealerweise hast du auch schon ein Projekt.
  2. Du lädst dir eine aktuelle Version von NUnit von der NUnit Homepage www.nunit.org runter.
  3. In deiner Projektmappe legst du nun ein neues leeres C# Projekt an (ProjektnameTest zum Beispiel)
  4. Nun im Menü unter „Extras“ -> „Einstellungen“ die Option „Experteneinstellungen“ wählen
  5. Damit wird dann der Menüeintrag „Externe Tools“ (unter „Extras“) überhaupt sichtbar.
  6. Dort dann NUnit wie folgt eintragen:
    NUnit als externes Tool in Visual C#
    Schlecht sichtbar, aber ich verlinke auf nunit-x86.exe, sonst funktioniert das bei mir nicht, da ich ein 64-Bit System habe.

So, euer System ist bereit, unter „Extras“ habt ihr nun einen neuen Menüpunkt „NUnit“, der euch das aktuelle Projekt testet, also euer Testprojekt. Achte darauf, dass du vorher auch immer das Testprojekt neu erstellen läßt, da NUnit immer die Assembly und die exe zu rate zieht und wenn die nicht auf dem aktuellem Stand ist kommen verfälschte Ergebnisse heraus.

Bei den Tests ist es wichtig, die aus PHP bekannten „Testsuiten“ mit dem Attribut [TestFixure] im (Test-)Code zu kennzeichnen, die Tests selbst als [Test], sonst funktioniert das Ganze nicht und NUnit meldet, es gäbe keine Tests zum Ausführen!

Für den Start hier mal ein kleines Beispiel für dich. Sicherlich stimmen noch nicht alle Namen und Bezeichner und die Test machen auch noch nicht viel Sinn, aber es soll ja mehr als eine Art „Quickstart“ gemeint sein, ein Grundgerüst zum Verständnis:

namespace apps.presnac
{
  using NUnit.Framework;

  [TestFixture]
  public class KeysTest
  {
    [Test]
    public void testingFileDefs()
    {
      FileDefinitions clsFiledefs = new FileDefinitions();
      FileDefinition[] filedefs = clsFiledefs.getFileDefinitions();

      Assert.AreEqual(filedefs.Length, 57);
    }

    [Test]
    public void testWillFail()
    {
      Assert.AreEqual(1, 2);
    }
  }
}

namespace UnitTesting
{
  public class deCHKTesting
  {
    public static void Main()
    {
      apps.presnac.KeysTest testingKeys = new apps.presnac.KeysTest();
      testingKeys.testingFileDefs();
      testingKeys.testWillFail();
    }
  }
}

Ja, in diesem Beispiel geht es um mein Grundgerüst zu meinem Projekt deCHK, was bald als neue Version komplett neu in C# geschrieben erscheinen wird.

Den unteren Block, die Klasse deCHKTesting mit der main()-Methode brauchst du, damit dein Projekt überhaupt eine ausführbare Datei erstellen kann, die dann von NUnit analysiert und zum testen herangezogen werden kann.

Und anschließend ein Blick auf die Testergebnisse:

nunit-testergebnisse

Also, Unit-testing in C# mit Visual Studio Express ist möglich, man muss nur 2 kleine Kniffe kennen (wie komme ich ans Tools Menü und die beiden Attribute im Code, um Tests zu markieren) und schon steht den kontrollierten Funktionssicherheitsnachweisen nichts mehr im Wege 😉 .

Was ich sehr unschön finde ist die Tatsache, dass es in Visual Studio nicht möglich ist, eine Standardvorgehensweise wie Unit Tests direkt in IDE zu integrieren. Vor allem da NUnit hier der Marktführer für .Net ist fällt es mir schwer, meine Tests nicht direkt in meiner IDE zu sehen und per Doppelklick auf einen aufgetretenen Fehler direkt zum zuständigen Code zu gelangen. Hier sollte Microsoft nachbessern, damit künftige C#-Entwickler auch in den Genuß von „Test-Driven-Development“ direkt in der VS-IDE kommen.

Ansonsten wünsche ich dir noch viel Erfolg beim Unit-Testen deines C#-Codes.