Jak podać ofertę pracy w PHPUnit?

Zajmuję się programowaniem stron internetowych od 15 lat, a PHP przez ostatnie 5 lat. Zawsze pisałem solidny kod. JEDNAK mam klienta, który nalega, aby 80% kodu było testowane jednostkowo. Ponieważ klient jest ZAWSZE PRAWIDŁOWY, planuję użyć PHP_CodeSniffer, aby upewnić się, że mój kod wygląda poprawnie, a PHPUnit do przeprowadzenia testów jednostkowych. Mam nadzieję nauczyć się czegoś dzięki temu doświadczeniu.

Czy są to odpowiednie narzędzia do użycia? Ile czasu zajmuje konfiguracja PHPUnit i napisanie dodatkowego kodu? Pisanie stron internetowych i autotest powinien zająć mi około 8 tygodni, tak jak robiłem to w przeszłości. Jeśli dodam dodatkowe 4 dni (10%) na testy jednostkowe (PHPUnit), czy to wystarczy? Myśli? Propozycje? Dzięki.

W jednym wierszu: zależy od tego, jak pracujesz. Uważam, że 10% to zdecydowanie za mało. Powinien wynosić co najmniej 25%, jeśli nie 40%, jeśli nie 60%, jeśli nie więcej.

Po pierwsze, bardzo zgadzam się z twoim klientem. Testy jednostkowe są istotną częścią solidnego, łatwego w utrzymaniu i łatwego do debugowania produktu.

Będę mówić z tego, co wiem. Używam TDD (Test-Driven Development) do większości projektów. TDD zasadniczo powoduje, że piszesz testy przed właściwym kodem. Ustanawiają zestaw kryteriów akceptacji, które musi spełniać produkt końcowy. Zwykle spędzasz od 50% do 70% czasu na pisaniu testów, a resztę na implementację kodu, aby je zdać.

Choć może to zabrzmieć absurdalnie i / lub ogromnie, zapewniam cię, że tak nie jest. Dlatego:

• Będziesz mógł dowiedzieć się, jakie wzorce architektoniczne najlepiej zastosować podczas pisania testów. W ten sposób, kiedy zaczniesz kodować, architektura aplikacji zmieni się minimalnie (ponieważ wszyscy wiemy, jak kosztowne jest ponawianie architektury aplikacji).
• Kodujesz tylko po to, aby testy przeszły pomyślnie (co sprawia, że ​​produkt końcowy jest dopuszczalny). Nie będziesz spędzać czasu na programowaniu bezużytecznych / poza zasięgiem funkcji.
• Mając mniej kodu (tj. Tylko taki kod, którego faktycznie potrzebujesz), jest on mniej podatny na błędy. (Mniej kodu = mniej błędów).
• Jeśli popełnisz błąd i tak zrobisz, zajmie to znacznie mniej czasu, aby dowiedzieć się, dlaczego jest problem i gdzie jest problem. Jeśli testy są napisane poprawnie, oznacza to, że pojedynczy błąd spowoduje pojedynczą awarię, a nie reakcję łańcuchową. W ten sposób możesz łatwo wskazać źródło problemu w ciągu kilku minut, jeśli nie sekund.
• Zaimplementowanie rzeczywistego kodu za pomocą testów jednostkowych zajmie o wiele mniej czasu. Gdy tylko test się nie powiedzie, wiesz, że coś jest nie tak. Nie musisz robić tam iz powrotem klienta, aby naprawić błędy.
• W końcu będziesz musiał zrobić to samo z klientem, aby naprawić błędy, ponieważ nic nie może uchwycić 100% błędów. Możesz jednak łatwo złapać 95%, jeśli nie więcej.

PHPUnit jest de facto narzędziem do testowania jednostek PHP i jest w tym bardzo dobry. Nie korzystałem dużo z PHP_CodeSniffer. Myślę jednak, że jeśli pracujesz sam, prawdopodobnie nie potrzebujesz go. Bardziej przydatne w zespole jest upewnienie się, że kod wygląda tak samo bez względu na to, kto go kodował.

Proponuje ci postawę, że nauczysz się czegoś na podstawie tego doświadczenia. Jestem pewien, że tak.

Pierwszą rzeczą, której powinieneś się nauczyć, jest to, że konieczność testów jednostkowych nie ma nic wspólnego z twoim doświadczeniem . Najlepszy programista będzie również jednym z najlepszych testerów jednostkowych:

Bill Venners: Mówisz w swojej książce Refaktoryzacja: „Jeśli chcesz refaktoryzować, niezbędnym warunkiem są solidne testy”. Czy to oznacza, że ​​jeśli nie masz testów, nie powinieneś refaktoryzować?

Martin Fowler: Powinieneś myśleć o tym jak chodzenie po linie bez siatki. Jeśli jesteś dobry w chodzeniu po linie i nie jest tak wysoko, możesz spróbować. Ale jeśli nigdy wcześniej nie chodziłeś po linie, a to nad wodospadem Niagara, prawdopodobnie potrzebujesz dobrej sieci.

^{Od http://www.artima.com/intv/refactorP.html}

Pisałem PHP bez testów jednostkowych. Potem, po latach praktykowania testów jednostkowych w Javie, odkryłem, że nie mogę pracować na niczym bardziej skomplikowanym niż pojedyncze strony w PHP bez testów jednostkowych. Powód? Produktywność . Bez testów jednostkowych nie mogłem pewnie refaktoryzować - oznaczało to, że albo A) będę musiał zburzyć znacznie więcej i pracować nad wszystkim od początku, albo B) , będę musiał poradzić sobie z brzydkim, starszym kodem.

Kiedy składasz ofertę, czy musisz wziąć pod uwagę czas na przetestowanie? Tak . Czy wydaje się intuicyjne, że zajmie to więcej czasu? Tak, jeszcze raz . Prawdopodobnie, jak z grubsza oszacowały niektóre inne odpowiedzi, będziesz musiał oszacować 50-100% więcej niż bez testów jednostkowych.

Jednak!...

• Wcześniej złapiesz i naprawisz dziury w specyfikacji
• Co oznacza, że ​​będziesz rozwijał się do czystszej i bardziej solidnej specyfikacji
• Będziesz mógł szybko i pewnie reagować na zmiany specyfikacji
• Będziesz miał mniej błędów
• Twoje błędy zostaną wykryte wcześniej i łatwiej będzie je naprawić

W rezultacie Twoje szacunki będą dokładniejsze . Jeśli pobierzesz opłatę za godzinę, bardziej zaimponujesz swoim klientom i będziesz w stanie podnieść stawki. Jeśli pobierzesz opłatę ryczałtową, zarobisz więcej pieniędzy na godzinę.

Bez testowania twoje prognozy najprawdopodobniej są bzdurą. Błędy, zlecenia zmian i redefinicje są bardzo trudne do dokładnego oszacowania. Testowanie jest kluczem do zminimalizowania wpływu wszystkich trzech!

Nie ma łatwej odpowiedzi na pytanie, ile czasu to zajmie.

Ale jako podstawową zasadę, jeśli jest to krótki projekt: Powiedziałbym, że rozwój wraz z dobrym testowaniem jednostkowym zajmie 1,75-2 razy dłużej niż rozwój bez testów jednostkowych. W przypadku dłuższych projektów może 25-30%?

Sugeruję wykonanie testów jednostkowych przed napisaniem kodu. W ten sposób zbudowanie rusztowania testu jednostkowego staje się częścią procesu projektowania, więc nie powinieneś brać pod uwagę, że tracisz czas na testy jednostkowe, ale raczej, że budowanie testu jednostkowego pomaga ci zaprojektować świetny produkt i istnienie tego testu po jego zbudowaniu ułatwia upewnienie się, że tak pozostanie. Pisanie testów jednostkowych na początku jest cudowne, ponieważ pomaga skupić się na rzeczywistych wymaganiach, daje nam jasny sposób sprawdzenia, czy jesteśmy skończeni (zaliczenie testów jednostkowych) i pomaga nam „testować wcześnie i często testować”.

Jeśli chodzi o PHPUnit ... Minęło trochę czasu, odkąd go użyłem, mam wrażenie, że jest potężny, ale być może potrzebuje trochę więcej pracy, zanim będzie naprawdę dopracowany.

Jeśli jest jednak jedna rzecz, którą chcę tutaj przekazać: proszę nie widzieć Testowania Jednostek jako zwykłej formalności na końcu projektu. Jeśli to wszystko, moim zdaniem, jest to bezwartościowe.

Odpowiedzi do tej pory są dość dokładne, więc dodam tylko jeden punkt nieuwzględniony: będzie dodatkowy czas związany z użyciem PHPUnit

1. początkowo wyższy, odkąd się go uczysz, i
2. skróć czas testowania bez testowania, gdy zyskasz pewność siebie.

Klasy modeli testów jednostkowych, które nie zajmują się prezentacją, są dość proste. Piszesz test dla każdej klasy, aw tych przypadkach testowych możesz bezpośrednio utworzyć instancję i skonfigurować obiekt do testowania określonej metody / funkcji. Gdy już skonfigurujesz i uruchomisz PHPUnit, będziesz w stanie szybko uruchomić testy.

Strony internetowe z testami jednostkowymi mogą być trudniejsze. Jeśli używasz Zend Framework, Symfony, Smarty lub dowolnego innego silnika MVC, sprawienie, by PHPUnit dobrze z nimi grało, może zająć więcej czasu. Używamy Zend Framework i spędziłem dużo czasu na budowaniu klas podstawowych do testowania kontrolerów i przeglądania skryptów w izolacji. Biorąc pod uwagę rozmiar tego projektu, prawdopodobnie lepiej zacząć od ControllerTestCase.