Moja interpretacja tego wystąpienia jest następująca:
- komponenty testowe, a nie klasy.
- testuj komponenty przez ich porty interfejsu.
Nie jest to określone w wykładzie, ale myślę, że założony kontekst porady jest podobny:
- tworzysz system dla użytkowników, a nie, powiedzmy, bibliotekę narzędziową lub platformę.
- Celem badania jest skutecznie dostarczać jak najwięcej w ramach budżetu konkurencyjnej.
- komponenty są pisane w jednym, dojrzałym, prawdopodobnie statycznie typowanym języku, takim jak C # / Java.
- komponent jest rzędu 10000-50000 linii; projekt Maven lub VS, wtyczka OSGI itp.
- komponenty są pisane przez jednego programistę lub ściśle zintegrowany zespół.
- kierujesz się terminologią i podejściem przypominającym architekturę sześciokątną
- port komponentu to miejsce, w którym zostawiasz język lokalny, a jego system typów, przełączając się na http / SQL / XML / bytes / ...
- Zawijanie każdego portu to interfejsy maszynowe, w sensie Java / C #, w których implementacje mogą być przełączane w celu przełączania technologii.
Zatem testowanie komponentu jest największym możliwym zakresem, w którym coś nadal można rozsądnie nazwać testowaniem jednostkowym. Różni się to raczej od tego, jak niektórzy ludzie, zwłaszcza akademicy, używają tego terminu. Nie przypomina to przykładów w typowym samouczku do testów jednostkowych. Jednak odpowiada to swojemu pochodzeniu podczas testowania sprzętu; płyty i moduły są testowane jednostkowo, a nie przewody i śruby. A przynajmniej nie budujesz fałszywego Boeinga do testowania śruby ...
Wyciągając z tego ekstrapolację i wtrącając własne myśli,
- Każdy interfejs będzie wejściem, wyjściem lub współpracownikiem (jak baza danych).
- Ci przetestować interfejsy wejściowe; wywołać metody, potwierdzić wartości zwracane.
- Państwo szydzić interfejsów wyjściowych; sprawdź, czy oczekiwane metody są wywoływane dla danego przypadku testowego.
- Państwo fałszywe współpracownicy; zapewnić proste, ale działające wdrożenie
Jeśli zrobisz to właściwie i czysto, ledwo potrzebujesz narzędzia kpiącego; zużywa się tylko kilka razy na system.
Baza danych jest zazwyczaj współpracownikiem, więc zostaje sfałszowana, a nie wyśmiewana. Wykonanie tego byłoby bolesne ręcznie; na szczęście takie rzeczy już istnieją .
Podstawowym wzorcem testowym jest wykonanie sekwencji operacji (np. Zapisanie i ponowne załadowanie dokumentu); potwierdź, że działa. Jest to to samo, co w przypadku każdego innego scenariusza testowego; żadna (działająca) zmiana implementacji prawdopodobnie nie spowoduje niepowodzenia takiego testu.
Wyjątkiem są zapisy bazy danych, które nigdy nie są odczytywane przez testowany system; np. dzienniki kontroli lub podobne. Są to dane wyjściowe i dlatego powinny być wyśmiewane. Wzorzec testowy wykonuje pewną sekwencję operacji; potwierdź, że interfejs kontroli został wywołany przy użyciu metod i argumentów określonych.
Zauważ, że nawet tutaj, pod warunkiem, że używasz bezpiecznego narzędzia do kpin typu mockito , zmiana nazwy metody interfejsu nie może spowodować niepowodzenia testu. Jeśli użyjesz IDE z załadowanymi testami, zostanie ono refaktoryzowane wraz ze zmianą nazwy metody. Jeśli nie, test nie zostanie skompilowany.