Nic odkrywczego dla osób troszkę więcej zajmujących się inżynierią oprogramowania i samym programowaniem nie powiem – testy. Ale nie pierwsze lepsze… tylko takie zautomatyzowane. Czyli to co tygrysy lubią najbardziej – jak zrobić, żeby się nie narobić .

No dobra, to ściema – nie do końca zautomatyzowane. Ktoś musi je napisać. A przygotowanie dobrych testów do jakiejś partii kodu potrafi zabrać co najmniej tyle czasu co samo napisanie tego kodu…

Ale, gdy mamy je już gotowe:
# bin/make_test
PHPUnit 3.0.6 by Sebastian Bergmann.
...........................S......S..............................
..........................F.S........S
Time: 00:02
There was 1 failure:
1) testUAString2Icon(FunctionsOtherTest)
[FUNC UA] Zla ikona UA dla systemu. Sprawdzalem pozycje '0' z UA 'Mozilla/5.0
(Windows; U; Windows NT 5.0; pl; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3' (z bazy '2').
Failed asserting that <boolean:false> is identical to <boolean:true>.
FAILURES!
Tests: 103, Failures: 1, Skipped: 4.
to jest naprawdę przydatne. Grzebiesz w kodzie, coś poprawiasz, jakaś mała modyfikacja API czy projektu i wywala się drugi koniec serwisu. Koniec na który nie wchodziłeś od roku . Co dają dobre testy? Szansę, że wychwycisz ten błąd.

Zautomatyzowane testy pisze się we frameworkach, jak np. JUnit, NUnit, CUnit i wiele innych. Jest i dla PHP – zowie się (uwaga – co na tle pozostałych może być zaskoczeniem): PHPUnit. Jeśli chcesz zacząć pracę z nim polecam oficjalny tutorial – PHPUnit Pocket Guide. Podstawy używania tłumaczy bardzo dobrze. Bardziej zaawansowane tematy, jak np. stuby do udawania obiektów czy funkcjonalności, są słabiej wytłumaczone, ale zdolny człek się połapie.