Międzyjęzykowy rozwój oparty na testach

Krótkie pytanie: Jak postępujesz zgodnie z testowaniem opartym na testach w projekcie obejmującym wiele języków?

W szczególności piszę aplikację internetową, która korzysta z JavaScript i PHP, i chcę przestrzegać zasad TDD, ale nie jestem pewien, jak je zintegrować. Czy uruchamiam osobne pakiety testowe dla sekcji JS i PHP i używam makiet w pakiecie JS do emulacji odpowiedzi serwera? Czy istnieje technika testowania jednostkowego obu komponentów w jednym cyklu?

To moje pierwsze doświadczenie z wykorzystaniem Test-Driven Development, więc każda rada, którą możesz podzielić się na temat tego, jak sprawić, by była mniej zniechęcająca, byłaby świetna. Wybrałem to dlatego, że jak tylko skończyłem prototyp, wymagania uległy zmianie, co zmusiło mnie do zmiany projektu. Pomyślałem, że jeśli zaczynam od nowa, od samego początku chciałbym napisać bardziej rozszerzalny kod z wbudowanymi testami regresji.

Piszę testy PHP w SimpleTest, a testy JavaScript w JsTestDriver. Jestem przyzwyczajony do paradygmatów obiektowych, więc mam kilka klas w PHP i robię coś podobnego w JavaScript używając prototypowego dziedziczenia. Zacząłem też czytać tę książkę o TDD w Pythonie i tę o TDD w JavaScript , ale z tego, co widziałem, nie opisują testowania aplikacji w całości (poza użyciem czegoś takiego jak Selenium lub inny sterownik sieciowy do przeprowadzania testów akceptacyjnych frontonu. Czy TDD nie jest po prostu przeznaczone dla programistów z pełnym stosem?

Czy istnieje technika testowania jednostkowego obu komponentów w jednym cyklu?

Byłoby to wręcz przeciwne do testowania jednostkowego - testowanie jednostkowe, szczególnie w stylu TDD, oznacza testowanie komponentów w izolacji . Tak więc odpowiedź brzmi tak: „uruchom osobne pakiety testowe dla sekcji JS i PHP ”, w przeciwnym razie nie jest to test jednostkowy, a nie TDD.

Oczywiście zautomatyzowane testy integracyjne mogą przetestować „oba komponenty w jednym przebiegu” i możesz użyć dokładnie tych narzędzi, o których już wspomniałeś (takich jak Selenium). Ale są to zazwyczaj bardziej złożone testy, opracowane poza cyklami TDD.

Ważne jest, aby odróżnić TDD od ATDD . AT oznacza „ testy akceptacyjne ”, a odnosi się to do rozwoju, w którym zaczynasz od testu akceptacyjnego, który prawdopodobnie przetestuje cały stos. Jest to również czasami nazywane „zewnętrznym rozwojem opartym na testach”. Kiedy ludzie mówią o TDD, „T” tam prawdopodobnie odnosi się konkretnie do testów jednostkowych .

Kluczową częścią testów jednostkowych jest izolowanie testowanej jednostki od jej zależności. Daje to dwie bardzo ważne korzyści:

• Możesz zrobić testy bardzo szybko, dzięki czemu możesz je uruchamiać bardzo często w ramach bardzo krótkiego cyklu sprzężenia zwrotnego. Zamiast uruchamiać je, powiedzmy, co godzinę, powinieneś być w stanie uruchamiać wszystkie testy jednostkowe po każdej drobnej zmianie, dzięki czemu natychmiast otrzymujesz ich opinie na temat tego, czy ta zmiana coś zepsuła.

• Twoje testy mogą być ukierunkowane na bardzo konkretne zachowanie. Jeśli jeden z nich zawiedzie, powinieneś być w stanie niemal natychmiast określić dokładną naturę błędu wskazywanego przez test.

Ze względu na znaczenie tej izolacji, będziesz automatycznie chciał, aby testy były ograniczone do znacznie mniejszych jednostek, niż wymuszają cię granice językowe. Chociaż nie jest to trudna i szybka reguła, często można oczekiwać, że jedna klasa będzie jednostką do przetestowania. Jeśli chodzi o TDD, problem językowy jest mniej lub bardziej nieistotny.

Z drugiej strony, jeśli chcesz korzystać z ATDD, upewnij się, że dokładnie zajrzysz do zasobów (jest to często wykonywane jako część BDD, więc spójrz również na narzędzia do tego ukierunkowane). Oto, gdzie naturalnie pasowałoby coś takiego jak Selenium. Zwykle podczas wykonywania ATDD nadal piszesz testy jednostkowe, a w rzeczywistości, aby przejść każdy test akceptacyjny, możesz przetestować jego implementację za pomocą testów jednostkowych. Więc nawet jeśli chcesz wykonać ATDD, zrozumienie, jak pisać testy jednostkowe, jest nadal ważne.

Nie musisz też używać TDD do pełnego stosu aplikacji. TDD jako metodyka programowania jest bardziej odpowiednia dla logicznych części aplikacji. Części, które wymagają bardziej eksperymentalnego dotyku, jak powiedziano, projekt interfejsu użytkownika, certyfikaty interakcji lub domena bazy danych są lepiej wykonane w tradycyjnym stylu, ponieważ nie wiesz jeszcze, czy to będzie ostateczna wersja.

Ale logika aplikacji nie powinna się zmieniać w przyszłości, a jeśli tak, stajesz w obliczu strasznego wymagania. To sprawia, że ​​idealnie nadaje się do zestawu testów regresji, aby dać pewność przy każdej zmianie kodu, co jest ostatecznym celem TDD.

Wujek Bob wyjaśnia to lepiej niż ja. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html