Mam sporą wiedzę na temat testów jednostkowych. Próbowałem przeczytać o umowach dotyczących kodu. Czy to naprawdę pomaga w testowaniu jednostkowym? Czy to jest przesadzone, szczególnie gdy mówimy o umowie kodowej pomagającej w przeprowadzaniu testów jednostkowych. Odnoszę się konkretnie do umów w .net 4.0. Używam nunit do testowania jednostkowego.Czy umowy na kody naprawdę pomagają w testowaniu jednostek?
Tak i Nie. Testy jednostkowe są w zasadzie umową, która mówi, że MyMethod() bierze X i oczekuje, że Y będzie wynikiem, a gdy tego nie zrobi, to testy jednostkowe zawiodą i zostaniesz ostrzeżony jako twórca MyMethod(), że się zepsułeś coś w tym. Umowy dotyczące kodu pomagają pisać testy jednostkowe, ponieważ wymagania w umowach ułatwiają poznanie wymagań testów jednostkowych podczas ich pisania. Jednak prawdziwy powód kontraktów kodu nie jest dla Ciebie, ale dla innych programistów korzystających z tworzonego API. Testy jednostkowe pozwalają poznać właściwe wejścia i wyjścia, ale kiedy wypuszczasz kod na wolność, testy jednostkowe nie są wydawane z rozszerzeniem .dll. Kontrakty na kod dają deweloperom inne korzyści z poznania, poprzez umowy na czas kompilacji i sprawdzenia, tych samych wymagań. Kontrakt chroni przed tymi programistami (ja), którzy mają okropną tendencję do nieodczytywania dokumentacji metod i po prostu zaczynają przekazywać rzeczy, więc teraz będą aktywnie ostrzegani przez kontrakty.
Nie, nie sądzę, że umowy kodowe pomagają w pisaniu testów jednostkowych. Testy jednostkowe określają zachowanie i ograniczenia danego działania. Jedna z tych specyfikacji napisana w testach jednostkowych może być taka, że argumenty metody nie mogą być puste.
W takim przypadku nadal trzeba napisać test jednostki. Umowa kodowa to sposób na wdrożenie specyfikacji, ale nie jedyny sposób.
Innymi słowy, nie zakładaj, że użycie umowy kodu oznacza, że nie musisz pisać testu jednostki! Jeśli ktoś zmieni umowę kodową lub ją usunie, nie będzie miał testu, który mówi, że ta zamierzona specyfikacja nie powiodła się.
Nie sądzę, aby ktokolwiek twierdził, że umowy kodowe powinny zastąpić testy jednostkowe. –
Zgadzam się, że umowy nie pomagają w pisaniu testów jednostkowych. Najlepiej byłoby, gdyby testy były na pierwszym miejscu, więc nie należy zawierać umów, dopóki nie zostanie sprawdzony test. Kontrakty można następnie napisać w celu egzekwowania wszelkich negatywnych ("należy rzucić") testów. –
Kontraktów kodowych można używać do celów, w których nie można stosować testów jednostkowych (umów na interfejsy). Stosowane są w łańcuchach dziedziczenia (gdzie można łatwo popełnić błędy przy ręcznym testowaniu jednostkowym). Zapewniają one automatyczną dokumentację (coś, czego testy jednostkowe nie mogą wykonać). Mogą zapewniać kontrole czasu wykonywania w trakcie produkcji (coś, czego nie mogą wykonać testy jednostkowe).
Z drugiej strony, umowy zawierane są tylko wtedy, gdy są realizowane, a więc bez testów jednostkowych nie masz zapewnień o jakości kodu (tzn. Że cały twój kod spełnia różne umowy). Te dwie koncepcje są bezpłatne.
Ale czy to nie powiela mojej logiki? Mam na myśli, że będziemy mieć tę samą logikę (warunki wstępne i końcowe) dla umów i testów jednostkowych. –
To będzie, iz punktu widzenia purystów, powinno, ponieważ jeśli ktoś przypadkowo usunie umowę, testy jednostkowe będą nadal weryfikować logikę, że nie chcesz, aby zrobił coś, co może teraz zrobić, lub na odwrót. Umowy mogą być wskazówką do pisania testów jednostkowych, ale nadal nie zastępują ich. –
Trudno mi zgodzić się, że kontrakty są duplikatami testów jednostkowych. Umowy dotyczące kodów określają wymagania, testy jednostkowe potwierdzają, że są prawdziwe. W pewnym sensie testy sprawdzają, czy twoje kontakty są poprawne - kontrakty są możliwym do dostarczenia kodem i dlatego powinny zostać przetestowane. –