W zależności od tego, gdzie spojrzysz, otrzymasz nieco inne odpowiedzi. Dużo czytałem na ten temat i oto moja destylacja; znowu są nieco wełniste i inni mogą się nie zgodzić.
Testy jednostkowe
Testuje najmniejszą jednostkę funkcjonalności, zazwyczaj metodę / funkcję (np. Biorąc pod uwagę klasę o określonym stanie, wywołanie metody x na klasie powinno spowodować, że y się zdarzy). Testy jednostkowe powinny koncentrować się na jednej konkretnej funkcji (np. Wywołanie metody pop, gdy stos jest pusty, powinno rzucić an InvalidOperationException). Wszystko, czego dotyka, powinno odbywać się w pamięci; oznacza to, że kod testowy i testowany kod nie powinny:
- Zawołaj do (nietrywialnych) współpracowników
- Uzyskaj dostęp do sieci
- Hit bazy danych
- Użyj systemu plików
- Zakręć nić
- itp.
Wszelką zależność, która jest powolna / trudna do zrozumienia / inicjalizacji / manipulacji, powinna zostać zagubiona / wyszydzona / poddana wielorakiej wymianie przy użyciu odpowiednich technik, abyś mógł skupić się na tym, co robi jednostka kodu, a nie na tym, co robią jej zależności.
Krótko mówiąc, testy jednostkowe są tak proste, jak to możliwe, łatwe do debugowania, niezawodne (ze względu na zmniejszone czynniki zewnętrzne), szybkie w wykonaniu i pomagają udowodnić, że najmniejsze elementy składowe programu działają zgodnie z przeznaczeniem, zanim zostaną złożone. Zastrzeżenie polega na tym, że chociaż możesz udowodnić, że działają idealnie w izolacji, jednostki kodu mogą wybuchnąć po połączeniu, co prowadzi nas do ...
Testy integracyjne
Testy integracyjne opierają się na testach jednostkowych poprzez połączenie jednostek kodu i sprawdzenie, czy powstała kombinacja działa poprawnie. Może to być wnętrze jednego systemu lub połączenie wielu systemów razem, aby zrobić coś pożytecznego. Kolejną rzeczą, która odróżnia testy integracyjne od testów jednostkowych, jest środowisko. Testy integracyjne mogą i będą wykorzystywać wątki, uzyskiwać dostęp do bazy danych lub robić wszystko, co konieczne, aby upewnić się, że cały kod i różne zmiany środowiska będą działać poprawnie.
Jeśli zbudowałeś jakiś kod serializacji, a urządzenie przetestowało jego wnętrzności bez dotykania dysku, skąd wiesz, że zadziała podczas ładowania i zapisywania na dysku? Może zapomniałeś spłukać i pozbyć się strumieni plików. Być może twoje uprawnienia do plików są niepoprawne i przetestowałeś wewnętrzne dodatki w strumieniach pamięci. Jedynym sposobem, aby się przekonać, jest przetestowanie go „na żywo” w środowisku najbliższym produkcji.
Główną zaletą jest to, że znajdą błędy, których testy jednostkowe nie mogą, takie jak błędy okablowania (np. Instancja klasy A nieoczekiwanie otrzymuje zerową instancję B) i błędy środowiskowe (działa dobrze na moim komputerze z jednym procesorem, ale mój 4-rdzeniowa maszyna kolegi nie może przejść testów). Główną wadą jest to, że testy integracyjne dotykają więcej kodu, są mniej niezawodne, awarie trudniejsze do zdiagnozowania, a testy trudniejsze do utrzymania.
Ponadto testy integracyjne niekoniecznie dowodzą, że działa pełna funkcja. Użytkownik może nie przejmować się wewnętrznymi szczegółami moich programów, ale robię to!
Testy funkcjonalne
Testy funkcjonalne sprawdzają poprawność określonej funkcji, porównując wyniki dla danych wejściowych ze specyfikacją. Testy funkcjonalne nie dotyczą samych wyników pośrednich ani skutków ubocznych, a jedynie wynik (nie obchodzi ich, że po wykonaniu x obiekt y ma stan z). Są one napisane w celu przetestowania części specyfikacji, takiej jak „wywołanie funkcji Square (x) z argumentem 2 zwraca 4”.
Test wstępny
Testy akceptacyjne wydają się być podzielone na dwa typy:
Standardowe testy akceptacyjne obejmują przeprowadzanie testów w pełnym systemie (np. Korzystanie ze strony internetowej za pomocą przeglądarki internetowej), aby sprawdzić, czy funkcjonalność aplikacji jest zgodna ze specyfikacją. Np. „Kliknięcie ikony powiększenia powinno powiększyć widok dokumentu o 25%”. Nie ma prawdziwego kontinuum wyników, tylko wynik pozytywny lub negatywny.
Zaletą jest to, że testy są opisane prostym językiem angielskim i zapewniają, że oprogramowanie jako całość jest kompletne. Wadą jest to, że przesunąłeś kolejny poziom w górę piramidy testowej. Testy akceptacyjne dotykają gór kodu, więc wyśledzenie awarii może być trudne.
Ponadto w zwinnym opracowywaniu oprogramowania testy akceptacji użytkownika obejmują tworzenie testów odzwierciedlających historie użytkowników tworzone przez / dla klienta oprogramowania podczas tworzenia. Jeśli testy przejdą pomyślnie, oznacza to, że oprogramowanie powinno spełniać wymagania klienta, a historie można uznać za kompletne. Pakiet testów akceptacyjnych to w zasadzie wykonywalna specyfikacja napisana w języku specyficznym dla domeny, który opisuje testy w języku używanym przez użytkowników systemu.
Wniosek
Wszystkie się uzupełniają. Czasami warto skupić się na jednym typie lub całkowicie go unikać. Główną różnicą jest dla mnie to, że niektóre testy patrzą na rzeczy z perspektywy programisty, podczas gdy inne wykorzystują ukierunkowanie na klienta / użytkownika końcowego.