Inne odpowiedzi wyjaśniają, czym jest drwina. Pozwól, że przeprowadzę cię przez różne przykłady . I uwierz mi, w rzeczywistości jest to o wiele prostsze niż myślisz.
tl; dr Jest to przykład oryginalnej klasy. Wprowadzono do niego inne dane, dzięki czemu unikniesz testowania wtryskiwanych części i skupisz się wyłącznie na testowaniu szczegółów implementacyjnych twojej klasy / funkcji.
Prosty przykład:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Jak widać, nie testuję LineA, tj. Nie sprawdzam poprawności parametrów wejściowych. Nie sprawdzam, czy num1, num2 są liczbami całkowitymi. Nie mam przeciwko temu żadnych zapewnień.
Testuję tylko, aby sprawdzić, czy LineB (moja implementacja ) poda wyśmiewane wartości 1i 5działa zgodnie z oczekiwaniami.
Oczywiście w prawdziwym słowie może to stać się znacznie bardziej złożone. Parametry mogą być niestandardowym obiektem, takim jak Osoba, Adres lub szczegóły implementacji mogą być więcej niż jednym +. Ale logika testowania byłaby taka sama.
Przykład niekodujący:
Załóżmy, że budujesz maszynę, która identyfikuje typ i markę urządzeń elektronicznych do ochrony lotniska. Maszyna robi to, przetwarzając to, co widzi za pomocą aparatu.
Teraz twój kierownik wchodzi do drzwi i prosi o przetestowanie ich w jednostce.
Następnie jako programista możesz przynieść 1000 prawdziwych obiektów, takich jak MacBook pro, Google Nexus, banan, iPad itp. I przetestować i sprawdzić, czy wszystko działa.
Ale możesz także użyć wyśmiewanych obiektów, takich jak identycznie wyglądający MacBook pro (bez prawdziwych części wewnętrznych) lub plastikowy banan przed nim. Możesz zaoszczędzić na inwestowaniu w 1000 prawdziwych laptopów i gnijących bananów.
Chodzi o to, że nie próbujesz sprawdzić, czy banan jest fałszywy, czy nie. Ani testowania, czy laptop jest fałszywy, czy nie. Wszystko robisz testuje jeśli urządzenie raz widzi banana byłoby powiedzieć, not an electronic devicea dla MacBooka Pro byłoby powiedzieć: Laptop, Apple. Dla maszyny wynik jego wykrycia powinien być taki sam dla fałszywej / wyśmiewanej elektroniki i prawdziwej elektroniki
Powyższa logika dotyczy również testowania jednostkowego rzeczywistego kodu. Ta funkcja powinna działać tak samo z rzeczywistymi wartościami uzyskanymi z rzeczywistych danych wejściowych (i interakcji) lub wyśmiewanymiwartości wprowadzane podczas testów jednostkowych. I podobnie jak oszczędzasz się przed używaniem prawdziwego banana lub MacBooka, dzięki testom jednostkowym (i kpinom) oszczędzasz siebie przed koniecznością zrobienia czegoś, co spowoduje, że Twój serwer zwróci kod statusu 500, 403, 200 itd. (Wymuszanie twój serwer wyzwala 500 tylko wtedy, gdy serwer jest wyłączony, a 200 gdy serwer jest włączony. Trudno jest uruchomić 100 testów sieciowych, jeśli musisz stale czekać 10 sekund między przełączaniem serwera w górę i w dół). Zamiast tego wstrzykujesz / wyśmiewasz odpowiedź kodem stanu 500, 200, 403 itd. I testujesz swoją jednostkę / funkcję za pomocą wstrzykniętej / wyśmiewanej wartości.
Przykład kodowania:
Powiedzmy, że piszesz aplikację na iOS i mają zadanie calls.Your sieć jest przetestować swoją aplikację. Testowanie / ustalanie, czy połączenia sieciowe działają zgodnie z oczekiwaniami, NIE JEST TO TWOJA ODPOWIEDZIALNOŚĆ. Testowanie go jest obowiązkiem innej strony (zespołu serwerów). Musisz usunąć tę zależność (sieciową), a mimo to kontynuować testowanie całego kodu, który działa wokół niej.
Połączenie sieciowe może zwrócić różne kody stanu 404, 500, 200, 303 itp. Z odpowiedzią JSON.
Twoja aplikacja powinna działać na wszystkie z nich (w przypadku błędów aplikacja powinna zgłosić oczekiwany błąd). To, co robisz z szyderstwem, to tworzenie „wymyślonych - podobnych do rzeczywistych” odpowiedzi sieciowych (takich jak kod 200 z plikiem JSON) i testowanie kodu bez „wykonywania prawdziwego połączenia sieciowego i oczekiwania na odpowiedź sieci”. Ręczne kodowanie / zwracanie odpowiedzi sieciowej dla WSZYSTKICH odpowiedzi sieciowych i sprawdzanie, czy aplikacja działa zgodnie z oczekiwaniami. (ty nigdy zakładać / przetestować 200 z błędnych danych, ponieważ to nie jest obowiązkiem, obowiązkiem jest, aby przetestować swoją aplikację z prawidłowym 200, lub w przypadku 400, 500, przetestować, czy aplikacja generuje właściwą błąd)
To tworzenie wymyślonego - podobnego do prawdziwego - nazywa się kpiną.
Aby to zrobić, nie możesz użyć oryginalnego kodu (oryginalny kod nie ma wstępnie wstawionych odpowiedzi, prawda?). Państwo musi dodać coś do niego, wstrzyknąć / wkładkę, która danych manekina, który normalnie nie jest potrzebne (lub część swojej klasie).
Więc utworzyć instancję oryginalnej klasy i dodać cokolwiek (tutaj jest sieć httpResponse, danych lub w przypadku awarii, przechodzą prawidłową errorString, httpResponse), należy do niego, a następnie przetestować szydzili klasę.
Krótko mówiąc, kpiny mają uprościć i ograniczyć to, co testujesz, a także nakarmić to, na czym polega klasa. W tym przykładzie unikają badania sieć nazywa się , a zamiast tego testu , czy aplikacja działa zgodnie z oczekiwaniami z wprowadzoną wyjść / odpowiedzi - przez wyśmianie klas
Nie trzeba dodawać, że każdą odpowiedź sieci testujesz osobno.
Teraz pytanie, które zawsze miałem na myśli, brzmiało: kontrakty / punkty końcowe i w zasadzie odpowiedź JSON moich API jest stale aktualizowana. Jak napisać testy jednostkowe, które biorą to pod uwagę?
Aby rozwinąć więcej na ten temat: powiedzmy, że model wymaga klucza / pola o nazwie username. Testujesz to, a test kończy się pomyślnie. 2 tygodnie później backend zmienia nazwę klucza na id. Twoje testy wciąż mija. dobrze? albo nie?
Czy to na deweloperze backendu spoczywa obowiązek aktualizowania próbnych wersji. Czy powinno być częścią naszej umowy, że dostarczają zaktualizowane symulacje?
Odpowiedzią na powyższy problem jest to, że: testy jednostkowe + proces programowania jako programista po stronie klienta powinien / będzie wychwytywać przestarzałe fałszywe odpowiedzi. Jeśli zapytasz mnie jak? odpowiedź brzmi:
Nasza rzeczywista aplikacja nie powiedzie się (lub nie zawiedzie, ale nie będzie miała pożądanego zachowania) bez użycia zaktualizowanych interfejsów API ... stąd jeśli to się nie powiedzie ... wprowadzimy zmiany w naszym kodzie programistycznym. Co ponownie prowadzi do niepowodzenia naszych testów ... które będziemy musieli poprawić. (W rzeczywistości, jeśli mamy poprawnie wykonać proces TDD, nie powinniśmy pisać żadnego kodu o polu, chyba że napiszemy test dla niego ... i zobaczymy, że się nie powiedzie, a następnie przejdziemy i napiszemy dla niego właściwy kod programistyczny.)
To wszystko oznacza, że backend nie musi mówić: „hej, zaktualizowaliśmy kpiny” ... w końcu dzieje się to poprzez tworzenie / debugowanie kodu. ّ Ponieważ to wszystko jest częścią procesu rozwoju! Chociaż jeśli backend zapewnia wyśmiewaną odpowiedź, jest to łatwiejsze.
Chodzi mi o to, że (jeśli nie możesz zautomatyzować pobierania zaktualizowanej fałszywej odpowiedzi API) wymagana jest interakcja człowieka, tj. Ręczne aktualizacje JSON i krótkie spotkania w celu upewnienia się, że ich wartości są aktualne, staną się częścią twojego procesu
Ta sekcja została napisana dzięki luźnej dyskusji w naszej grupie spotkań CocoaHead
Tylko dla deweloperów iOS:
Bardzo dobrym przykładem drwiny jest ta praktyczna zorientowana na protokół rozmowa Natashy Muraschev . Wystarczy przejść do minuty 18:30, chociaż slajdy mogą nie być zsynchronizowane z rzeczywistym filmem 🤷♂️
Bardzo podoba mi się ta część z transkrypcji:
Ponieważ to jest testowanie ... chcemy się upewnić, że getfunkcja z Gettablejest wywoływana, ponieważ może ona wrócić, a funkcja teoretycznie może przypisać tablicę artykułów spożywczych z dowolnego miejsca . Musimy się upewnić, że to się nazywa;