Ocena:
Recenzje książki „Design Driven Testing: Test Smarter, Not Harder” są mieszane - niektórzy czytelnicy chwalą zawarte w niej spostrzeżenia na temat metodologii testowania, a inni krytykują ją za stronniczy atak na Test Driven Development (TDD). Podczas gdy niektórzy uznali książkę za pomocne źródło, które zapewnia jasność i praktyczne przykłady, inni uważają, że brakuje jej treści, promuje inne prace autorów i zawiera nieścisłości dotyczące TDD.
Zalety:Czytelnicy docenili w książce świeże spojrzenie na metodologie testowania, w szczególności nacisk na testowanie oparte na projektowaniu (DDT) zamiast tradycyjnego rozwoju opartego na testach (TDD). Styl pisania jest jasny i zwięzły, z praktycznymi przykładami, które pomagają w zrozumieniu pojęć. Niektórzy uważają, że jest to pomocne źródło informacji w zakresie doskonalenia technik testowania w procesie tworzenia oprogramowania.
Wady:Krytycy twierdzą, że książka odrzuca TDD bez odpowiedniego zrozumienia i jest pełna nieścisłości na temat zwinnych metodologii. Niektórzy uważają, że jest to materiał promocyjny dla własnych produktów autorów, w szczególności ICONIX, a nie rzetelna eksploracja DDT. Dodatkowo, książka zakłada znajomość pewnych narzędzi i wcześniejszych prac, co może ograniczać jej dostępność dla szerszego grona odbiorców. Kilku recenzentów określiło treść jako powtarzalną i suchą.
(na podstawie 11 opinii czytelników)
Design Driven Testing: Test Smarter, Not Harder
W tym rozdziale zilustrowaliśmy, jak przeprowadzać testy jednostkowe na podstawie projektu oprogramowania, identyfikując scenariusze testowe w systematyczny sposób, który zapewnia pokrycie kodu we wszystkich właściwych miejscach. Zilustrowaliśmy również użycie "usług kaskaderskich" i obiektów pozorowanych w celu odizolowania testowanego kodu; na koniec omówiliśmy kierowanie testów jednostkowych głębiej w kod algorytmiczny, który może skorzystać z bardziej drobnoziarnistych testów.
Czy istnieje sposób na uzyskanie 95% korzyści z kompleksowych testów jednostkowych, które przeprowadziliśmy w tym rozdziale, przy znacznie mniejszej liczbie testów? W następnym rozdziale pokażemy, jak to zrobić za pomocą testów kontrolera. Jak zobaczysz, testy jednostkowe mają swoje miejsce, ale testy kontrolerów mogą często reprezentować inteligentniejsze, bardziej ustrukturyzowane podejście do testowania aplikacji. 136 C H A P T E R 6??? Projekt koncepcyjny i testowanie kontrolerów Jak już zauważyłeś w rozdziale 5, testowanie jednostkowe nie musi polegać na wyczerpującym pokryciu testami każdej pojedynczej linii kodu, a nawet każdej pojedynczej metody.
Istnieje prawo malejących zysków - i rosnących trudności - w miarę zwiększania percentyla pokrycia kodu. Cofając się o krok i patrząc na projekt w szerszej skali, można wybrać kluczowe obszary kodu, które działają jako punkty wejścia/wyjścia, i skupić testy na tych obszarach.
© Book1 Group - wszelkie prawa zastrzeżone.
Zawartość tej strony nie może być kopiowana ani wykorzystywana w całości lub w części bez pisemnej zgody właściciela.
Ostatnia aktualizacja: 2024.11.13 21:45 (GMT)