Dziś stanąłem przed zadaniem poprawienia komponentu, który automatyzuje nam kwestię wyszukiwania elementów w listingach.
Jego działanie można opisać z grubsza tak:
Na przykład jeśli chcę, żeby moja lista kosztów (Cost) mogła być wyszukiwana po nazwach – dodaję formularz z Cost.name i w akcji kontrolera wywołuję jedynie
$conditions = $this->Search->getConditions($this->params);
$this->paginate("conditions"=>$conditions);
$this->set('costs', $this->paginate('Cost'));
Największy bajer polegał na tym, że jeżeli moje koszty były powiązane z samochodami (Car) to chcą wyszukiwać po nazwie samochodu wystarczyło, że dodałem do formularza pole Car.name. Mój komponent potrafił zorientować się, że to jest powiązany model, wyszukać elementy spełniające warunek, a następnie zwrócić w conditions coś takiego:
Array
(
[and] => Array
(
[Cost.id] => Array
(
[0] => 1
[1] => 2
[2] => 5
[3] => 9
[4] => 10
[5] => 13
[6] => 17
[7] => 18
)
)
)
Gdzie cake ładnie sobie to przerabiał na zapytanie (w przybliżeniu)
Select * from costs as Cost where Cost.id IN (1, 2, 5, 9, 10, 13, 17, 18)
Byłem bardzo zadowolony z komponentu. Służył nam dzielnie przez przynajmniej dwie ostatnie iteracje. Każdą wyszukiwarkę/filtr dodawaliśmy w 5 minut na żądanie klienta (wewnętrznego ;)).
Mało tego, dość dużym wyzwaniem było sporządzenie testów dla tego komponentu (kilka MockObjects nawet się tam pojawiło) – pewnie dlatego tak sumiennie je wykonałem – 91% (z hakiem!) pokrycia kodu przez testy.
Przyszedł jednak dzień, gdy podczas prezentacji iteracji szef (klient wewnętrzny) powiedział (cytat nie dosłowny):
“Chcę jeszcze filtrować koszty wg numerów faktur (Invoice.number) z którymi te koszty są powiązane”
Problem w tym, że koszty są powiązane z fakturami poprzez elementy faktur (InvoiceElement), a konkretniej
Cost habtm InvoiceElement belongsTo Invoice
Zatem przyszło mi poprawić komponent, przy czym szczęśliwie zdążyłem zapomnieć wszystkich niuansów, foreachów i innych takich, które harcowały wewnątrz search_component.php. Myślę sobie – ok, tak jak poprzednio – dużo testów. Ale nie wiedziałem jak się do nich zabrać. Wiedziałem jedynie, że nazwa pola dla nowego przypadku powinna zawierać ścieżkę powiązań (np. InvoiceElement.Invoice.number).
Mając jednak w głowie dość przydatną radę na temat unit testów, która brzmi:
Najlepsze są testy napisane przed kodem. Jednocześnie napisanie najpierw kodu, a potem testów jest o niebo lepsze od braku jakichkolwiek testów.
Dlatego postanowiłem od razu przejść do próby implementacji nowych elementów dbając jedynie o kondycję dotychczasowych testów.
To co się wydarzyło można nazwać chyba “uprzężą testową”. Mogłem odważnie śmigać po dotychczasowo napisanym kodzie, bo w tym samym czasie zielone pole w rezultatach testów mówiło mi “śmiało dalej! niczego do tej pory nie popsułeś!”. Wspaniałe uczucie.
Wprawdzie po skończeniu pokrycie kodu spadło do 80% (nota bene i tak świetny wynik, 70% uznaje się za przyzwoite pokrycie), ale zaraz po napisaniu tego postu zabieram się za sporządzenie przynajmniej kilku testów. Trzeba zdążyć przed urlopem ;)
(*) Ta miłość jest nieodwzajemniona, gdy temat rozmowy schodzi na Fixture’y. Pewnie dlatego ten komponent testuje się tak ładnie i szybko – nie korzysta z bazy, tylko z Mock’owanych obiektów.