Artikel
Tests, Tests … PHPUnit-Tests!
Ein Praxisbeispiel, wie Unit-Tests Ihnen als Profi helfen können
Als Entwickler begegnen Ihnen viele Arten, Code zu schreiben, und viele Ideen. Manche sind gelungen, und Sie staunen, wie elegant und durchdacht die Lösung umgesetzt ist. Bei anderen fragen Sie sich ernsthaft, wie ein Entwickler so schlechten Code schreiben kann.
Oft wird das mit Sätzen wie „Hey, es funktioniert doch“ oder „Hey, die Kunden und das Geld kommen rein, also ist alles in Ordnung“ abgetan. Ja, das stimmt zu 100 %. Als Product Owner oder Unternehmer sollten Sie aber verstehen, dass Sie damit bestenfalls ein mittelmäßiges Produkt haben, wenn nicht sogar ein schlechteres.
Vor Kurzem hat mir ein Kunde seinen Code übergeben, damit ich neue Features umsetze, und ich fand eine Laravel-Anwendung mit einer SQL-Datei vor :). Sie ahnen es wahrscheinlich schon … die Migrations waren nicht auf dem Stand der Datenbank, und die SQL-Datei war die Quelle der „Wahrheit“.
Falls Sie sich fragen, warum oder wie so etwas passieren kann: Ganz einfach, so ist das Leben als Entwickler – voller Herausforderungen. Ich erinnere mich, dass mir solche Situationen als Junior-Entwickler Angst gemacht haben und ich den Kunden damit wahrscheinlich allein gelassen hätte. Mit der Zeit habe ich gelernt, „das Chaos zu übernehmen“ (own the mess). Am besten beschreibt diesen Prozess das Buch „Clean Code“ von Robert C. Martin (Uncle Bob).
Zurück zum Kunden: Ich war kurz davor, ihm zu sagen „Das ist Murks, das kostet mehr“ oder „Das mache ich nicht“. Denn Sie können sich vorstellen, dass auch im restlichen Code an so etwas wie PSR-2 nicht einmal zu denken war. Aus meiner Sicht ist das das grundlegende Minimum, das ein Entwickler leisten sollte. Wie auch immer: Ich habe „das Chaos übernommen“ und mit meiner Aufgabe weitergemacht. Ich habe mir die SQL-Datei angesehen, sämtliche Migrations in einen sauberen Ablauf überführt und weitergearbeitet.
Warum ich das gemacht habe? Meine Antwort: Ich habe keine Angst vor „Legacy Code“ oder „Spaghetti-Code“. In solchem Code finde ich meistens echte Perlen, und als Ergebnis meiner Arbeit habe ich PHPUnit-Tests eingeführt.
Das führt zu einem weiteren Thema: warum Sie zumindest versuchen sollten, Tests in Ihr Projekt zu bringen, und bei einem neuen Projekt einfach direkt auf TDD setzen sollten. Ich weiß, das kostet enorm viel Zeit und ist sehr anstrengend, aber langfristig ist der Nutzen riesig. Stabilität und Zuverlässigkeit Ihrer Software sind dann dauerhaft gegeben! Wenn die Tests gut geschrieben sind und Sie den Code richtig testen, sind Sie nah dran, ein besserer Entwickler zu sein als die Mehrheit.
Oft wird das mit Sätzen wie „Hey, es funktioniert doch“ oder „Hey, die Kunden und das Geld kommen rein, also ist alles in Ordnung“ abgetan. Ja, das stimmt zu 100 %. Als Product Owner oder Unternehmer sollten Sie aber verstehen, dass Sie damit bestenfalls ein mittelmäßiges Produkt haben, wenn nicht sogar ein schlechteres.
Vor Kurzem hat mir ein Kunde seinen Code übergeben, damit ich neue Features umsetze, und ich fand eine Laravel-Anwendung mit einer SQL-Datei vor :). Sie ahnen es wahrscheinlich schon … die Migrations waren nicht auf dem Stand der Datenbank, und die SQL-Datei war die Quelle der „Wahrheit“.
Falls Sie sich fragen, warum oder wie so etwas passieren kann: Ganz einfach, so ist das Leben als Entwickler – voller Herausforderungen. Ich erinnere mich, dass mir solche Situationen als Junior-Entwickler Angst gemacht haben und ich den Kunden damit wahrscheinlich allein gelassen hätte. Mit der Zeit habe ich gelernt, „das Chaos zu übernehmen“ (own the mess). Am besten beschreibt diesen Prozess das Buch „Clean Code“ von Robert C. Martin (Uncle Bob).
Zurück zum Kunden: Ich war kurz davor, ihm zu sagen „Das ist Murks, das kostet mehr“ oder „Das mache ich nicht“. Denn Sie können sich vorstellen, dass auch im restlichen Code an so etwas wie PSR-2 nicht einmal zu denken war. Aus meiner Sicht ist das das grundlegende Minimum, das ein Entwickler leisten sollte. Wie auch immer: Ich habe „das Chaos übernommen“ und mit meiner Aufgabe weitergemacht. Ich habe mir die SQL-Datei angesehen, sämtliche Migrations in einen sauberen Ablauf überführt und weitergearbeitet.
Warum ich das gemacht habe? Meine Antwort: Ich habe keine Angst vor „Legacy Code“ oder „Spaghetti-Code“. In solchem Code finde ich meistens echte Perlen, und als Ergebnis meiner Arbeit habe ich PHPUnit-Tests eingeführt.
Das führt zu einem weiteren Thema: warum Sie zumindest versuchen sollten, Tests in Ihr Projekt zu bringen, und bei einem neuen Projekt einfach direkt auf TDD setzen sollten. Ich weiß, das kostet enorm viel Zeit und ist sehr anstrengend, aber langfristig ist der Nutzen riesig. Stabilität und Zuverlässigkeit Ihrer Software sind dann dauerhaft gegeben! Wenn die Tests gut geschrieben sind und Sie den Code richtig testen, sind Sie nah dran, ein besserer Entwickler zu sein als die Mehrheit.