Powinieneś używać metod "Weryfikuj" i "Zweryfikuj" dostarczonych przez Moq w twoich testach jednostkowych?

Question

Wygląda na to, że używa się ich jako metody sprawdzającej, czy prawidłowo wykonana metoda jest szkodliwa, ponieważ doprowadzi do kruchej próby. Innymi słowy, wiążesz test z wdrożeniem. Więc jeśli później chcesz zmienić implementację, będziesz musiał zmienić test. Zadaję to pytanie, ponieważ zostałem przeszkolony do używania co najmniej jednej z tych metod w każdym teście jednostkowym i myślę, że mogłem właśnie mieć objawienie, że jest to w rzeczywistości bardzo zła praktyka.

Answer 1

Mock oparte testowanie

Jest wiele dyskusji wokół kruchości mocks w testach jednostkowych i czy są one dobre czy nie. Osobiście uważam, że jest to kompromis między utrzymaniem i solidnością.Im więcej kodu produkcyjnego podłożysz pod unit test pressure, testując go w izolacji z próbkami, tym mniej możliwych implementacji przejdzie pomyślnie. W ten sposób możesz zmusić swój kod produkcyjny do solidności i dobrego projektu. Z drugiej strony wiąże się ona z konkretną implementacją i zwiększa obciążenie konserwacyjne, ponieważ więcej testów będzie musiało zostać zmienionych natychmiast po zmianie szczegółów implementacji.

VerifyAll składnia()

To głównie kwestia gustu, ale uważam, że VerifyAll() nie jest intencją odkrywcze, to znaczy, kiedy czytasz zestaw testów można oczekiwać, aby uzyskać dobry pomysł specyfikacji po prostu patrząc na twierdzenia, a VerifyAll() nie ma żadnego znaczenia. Nawet gdy piszę próbne testy preferuję podejście Arrange Act Assert z określonymi komunikatami o błędach assert. Jest wyraźniejszy i mniej "magiczny" niż połączenie typu catch-all VerifyAll().

Korzystanie VerifyAll() w każdym i każdą metodę testową

To jest w najlepszym wypadku przesadą, aw najgorszym spowodować uszkodzenie zestawu testowego.

• Zgodnie z ogólną zasadą test jednostkowy powinien testować tylko jedną rzecz. Systematycznie wywoływanie VerifyAll() oprócz zwykłego stwierdzenia wprowadza zamieszanie - jeśli test się nie powiedzie, nie będziesz wiedział na pewno, co poszło nie tak.

• Jeśli chodzi o czytelność, dodajesz hałas do każdego z testów. To bardzo trudne, po prostu czytając metodę testową, aby prześledzić, co naprawdę oznacza ta VerifyAll().

• Generalnie chcesz wybrać, w którym miejscu zastosujesz nacisk na swoje implementacje z mockami i nie stosuj go na ślepo wszędzie, ponieważ jest cena utrzymania.

Więc jeśli naprawdę trzeba używać VerifyAll(), lepiej napisać osobne testy dla niej IMO.

Answer 2

Preferowanym sposobem jest użycie AAA. Ale w przypadku zależności zewnętrznych z pustym typem zwracania (powiedzmy void WriteData (Data data)), funkcja Verify może być przydatna (lub Setup, a następnie VerifyAll).

Answer 3

Przede wszystkim ważne jest, aby zrozumieć, że Verify metody -family są tam nie bez powodu - one pozwalają przetestować niezauważalny zachowanie systemu. Co mam przez to na myśli? Rozważ prosty przykład generowania aplikacji i wysyłania raportów. Ostateczny komponent będzie najprawdopodobniej wyglądał następująco:

public void SendReport(DateTime reportDate, ReportType reportType) 
{ 
    var report = generator.GenerateReport(reportDate, reportType); 
    var reportAsPlainText = converter.ConvertReportToText(report); 
    reportSender.SendEmailToSubscribers(body: reportAsPlainText); 
} 

Jak testujesz tę metodę? Nie zwraca niczego, więc nie można sprawdzić wartości. Nie zmienia stanu systemu (np. Rzuca flagę), więc nie możesz tego sprawdzić. Jedynym widocznym wynikiem wywołania SendReport jest fakt, że raport został wysłany przez wywołanie SendEmailToSubscribers. Jest to główna odpowiedzialność metody SendReport - i to właśnie testy jednostkowe powinny zweryfikować.

Oczywiście testy jednostek nie powinny i nie sprawdzają, czy wysłano lub dostarczono jakąś wiadomość e-mail. Zweryfikujesz mock z reportSender. I tu używasz metod Verify. Aby sprawdzić, czy rzeczywiście miało miejsce połączenie z próbą.

W końcowej nocie, Roy Osherove w książce Art Of Unit Testing (2nd edition) oddziela testy jednostkowe na trzy kategorie, w zależności od co można sprawdzić: wartość

• zwrotnego metody (prosty, wspólny)
• zmiana w stanie systemu (proste, rzadkie)
• wezwanie do urządzenia zewnętrznego (kompleks, rzadki)

Ostatnia kategoria jest wywoływanie używasz na nich metod mocks i Verify. Dla pozostałych dwóch wystarczą stubsy (metody Setup).

Kiedy twój kod jest zaprojektowany prawidłowo, taki test będzie (ostatnia kategoria) w mniejszości w bazie kodu, gdzieś w zakresie 5% - 10% (liczba pobrana z książki Roya, zgodnie z moimi spostrzeżeniami).

---

^{: niedostrzegalna jak w tym rozmówcy nie można łatwo sprawdzić, co dokładnie wydarzyło się po zakończeniu rozmowy.}