Czytałem wiele rzeczy o TDD, ale wciąż mam wątpliwości. Na przykład mam te diagramy klas:
To prosty przykład, aby dowiedzieć się więcej o TDD i próbnych obiektach.
Który test powinienem napisać jako pierwszy? Produkt , następnie linia i ostatni, zamówić ? Jeśli to zrobię, czy powinienem używać Linii i Produktu do testowania Zamówienia, czy też powinienem używać Próbnych Obiektów? Kiedy powinienem używać Mock Objects? Czy powinienem używać UML z XP i TDD?
Nie rozumiem jeszcze tych rzeczy.
Odpowiedzi:
Sądząc z diagramu, produkt jest głupią klasą danych, bez funkcji do testowania. Zacznę więc pisać testy dla (i implementacji, stylu TDD) pierwszej linii, a potem porządku, w górę drabiny zależności. Zazwyczaj rozsądne jest przetestowanie klas niższego poziomu przed rozpoczęciem pracy na klasach wyższego poziomu (tj. Zależnych od niższego poziomu). To sprawia, że łapanie błędów jest bardziej wydajne.
To, czy chcesz użyć obiektów pozornych, zależy od rzeczywistych zależności testowanej klasy. Jeśli są to proste klasy, które można łatwo utworzyć i skonfigurować z dowolnymi danymi / stanami wymaganymi do testów, nie trzeba próbować. (Wydaje się, że tak jest w przypadku twojego przykładowego projektu.) Jednak jeśli którakolwiek z zależności jest trudna do zainicjowania / sama ma rozległe zależności / ma niepożądane skutki uboczne / zależy od zewnętrznego zasobu, takiego jak baza danych, to ma to sens zamiast tego użyć próbnego obiektu.
Nie widzę tu zbytniej potrzeby na fałszywe obiekty. Jak zauważyli inni, potrzebujesz ich głównie, jeśli zależności są trudne do skonfigurowania.
Na przykład używaliśmy ich z projektami Ruby on Rails, kiedy testowaliśmy kontrolery i potrzebowaliśmy loginu użytkownika, który wymagałby połączenia z innym kontrolerem i przechowywania części jego informacji w pliku cookie. W takim przypadku pomocne jest wyśmiewanie zalogowanego użytkownika, który zwraca wartość true, gdy zostanie zapytany o określone uprawnienia dostępu.
Zwykle do testowania chcesz odizolować testowany system / obiekt, aby wyśmiewać wszystko, co jest poza tym. Korzystając z diagramu klas, podczas testowania obiektu zamówienia, użyj makiety obiektu liniowego. Podczas testowania linii użyj makiety zamówienia i produktu. Podczas testowania produktu użyj makiety linii.
„TDD to przede wszystkim technika projektowania, której efektem ubocznym jest sprawdzenie, czy kod źródłowy jest dokładnie testowany jednostkowo” - Scott W. Ambler
Chodzi o to, aby znaleźć projekt, pisząc testy jednostkowe. W twoim przypadku wydaje się, że masz już gotowy projekt, który niejako podważa cel TDD (zakładając, że twój projekt jest ostateczny).
Odnośnie kpiny. Jeśli chcesz kpić, sugeruję wyśmiewać Produkt podczas pisania testów dla Linii i próbować Linii podczas testowania Zamówienia. Ale tutaj może być przesada. Osobiście staram się ograniczać kpiny tak bardzo, jak to możliwe, i używam go do rozdzielania zależności od klas zewnętrznych (takich jak instancje bazy danych).