Dla mnie kluczową różnicą jest to, że testy integracyjne ujawniają, czy dana funkcja działa, czy jest zepsuta, ponieważ kładą nacisk na kod w scenariuszu zbliżonym do rzeczywistości. Przywołują jedną lub więcej metod lub funkcji oprogramowania i sprawdzają, czy działają zgodnie z oczekiwaniami.
Przeciwnie, test jednostkowy testujący pojedynczą metodę opiera się na (często błędnym) założeniu, że reszta oprogramowania działa poprawnie, ponieważ jawnie kpi z każdej zależności.
Dlatego, gdy test jednostkowy metody implementującej jakąś funkcję jest zielony, nie oznacza to, że funkcja działa.
Powiedz, że masz taką metodę:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomethingjest bardzo ważny dla twojego klienta: to funkcja, jedyna rzecz, która ma znaczenie. Dlatego zwykle piszesz specyfikację Ogórka, potwierdzając ją: chcesz zweryfikować i poinformować, że funkcja działa, czy nie.
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
Bez wątpienia: jeśli test się powiedzie, możesz stwierdzić, że dostarczasz działającą funkcję. To właśnie można nazwać wartością biznesową .
Jeśli chcesz napisać test jednostkowy DoSomething, powinieneś udawać (używając niektórych prób ), że pozostałe klasy i metody działają (to znaczy, że wszystkie zależności, których używa metoda, działają poprawnie) i upewnić się, że metoda działa.
W praktyce robisz coś takiego:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
Możesz to zrobić za pomocą Dependency Injection, metody Factory lub dowolnego Mock Framework lub po prostu rozszerzając testowaną klasę.
Załóżmy, że występuje błąd Log.DoSomething(). Na szczęście specyfikacja Korniszon znajdzie to, a kompleksowe testy zakończą się niepowodzeniem.
Ta funkcja nie działa, ponieważ Logjest zepsuta, a nie dlatego, że [Do your job with someInput]nie wykonuje swojej pracy. A tak przy okazji, [Do your job with someInput]to jedyna odpowiedzialność za tę metodę.
Załóżmy również, że Logjest używany w 100 innych funkcjach, w 100 innych metodach z 100 innych klas.
Tak, 100 funkcji zakończy się niepowodzeniem. Ale na szczęście 100 kompleksowych testów również nie udaje się i ujawnia problem. I tak: mówią prawdę .
To bardzo przydatna informacja: wiem, że mam zepsuty produkt. Jest to również bardzo myląca informacja: nie mówi mi nic o tym, gdzie jest problem. Przekazuje mi objaw, a nie pierwotną przyczynę.
Jednak DoSomethingtest jednostkowy jest zielony, ponieważ wykorzystuje fałszywy Log, zbudowany tak, aby nigdy się nie łamał. I tak: wyraźnie kłamie . Komunikowanie, że uszkodzona funkcja działa. Jak to może być przydatne?
(Jeśli DoSomething()test jednostkowy nie powiedzie się, upewnij się: [Do your job with someInput]ma kilka błędów.)
Załóżmy, że jest to system z uszkodzoną klasą:
Jeden błąd spowoduje uszkodzenie kilku funkcji, a kilka testów integracji zakończy się niepowodzeniem.
Z drugiej strony ten sam błąd przerwie tylko jeden test jednostkowy.
Teraz porównaj dwa scenariusze.
Ten sam błąd przerwie tylko jeden test jednostkowy.
- Wszystkie funkcje używające uszkodzonego
Logsą czerwone
- Wszystkie testy jednostkowe są zielone, tylko test jednostkowy
Logjest czerwony
W rzeczywistości testy jednostkowe dla wszystkich modułów korzystających z uszkodzonej funkcji są zielone, ponieważ dzięki próbom usunięto zależności. Innymi słowy, działają w idealnym, całkowicie fikcyjnym świecie. Jest to jedyny sposób na izolowanie błędów i poszukiwanie ich. Testowanie jednostkowe oznacza kpiny. Jeśli nie kpisz, nie przeprowadzasz testów jednostkowych.
Różnica
Testy integracyjne pokazują, co nie działa. Ale nie mają sensu zgadywać, gdzie może być problem.
Testy jednostkowe to jedyne testy, które pokazują, gdzie dokładnie jest błąd. Aby narysować te informacje, muszą uruchomić metodę w fałszywym środowisku, w którym wszystkie inne zależności powinny działać poprawnie.
Dlatego myślę, że twoje zdanie „Czy to tylko test jednostkowy obejmujący 2 klasy” jest w jakiś sposób przesunięte. Test jednostkowy nigdy nie powinien obejmować 2 klas.
Ta odpowiedź jest w zasadzie streszczeniem tego, co tu napisałem: Testy jednostkowe kłamią, dlatego je uwielbiam .
