Mam klasę z jedną metodą publiczną Send()i kilkoma metodami prywatnymi. Wywołuje kilka usług sieciowych i przetwarza odpowiedź. Przetwarzanie odbywa się metodami prywatnymi.
Chcę przetestować kod jednostki. Rozumiem, że testy jednostkowe powinny testować mój kod w oderwaniu (tj. Próbne odpowiedzi dostawcy).
Uważam również, że prywatne metody nie powinny wymagać testowania jednostkowego. Ale jeśli tylko przetestuję metodę Send (), mój kod nie będzie testowany w izolacji i zależy od odpowiedzi dostawcy.
Czy powinienem następnie podać moje prywatne metody do publicznej wiadomości, aby móc je przetestować za pomocą fałszywych odpowiedzi? Wydaje się to złą praktyką, ponieważ tylko ja powinienem do nich zadzwonić.
Przepraszamy, jeśli jest to podstawowe pytanie, jestem całkiem nowy w testach jednostkowych.
Używam c # i VS2010
źródło
Odpowiedzi:
Należy oddzielić kod dotyczący usług internetowych (tj. Wysyłanie i odbieranie danych) od kodu przetwarzającego wyniki. Przenieś ten ostatni kod do odrębnej klasy, upubliczniając niezbędne metody. Następnie możesz w łatwy sposób przetestować logikę przetwarzania w oderwaniu od zewnętrznych zależności.
W ten sposób dostosowujesz swój kod do zasady pojedynczej odpowiedzialności . Zasadniczo odczucie potrzeby testowania metod prywatnych często wskazuje na to, że klasa ma zbyt wiele obowiązków, dlatego należy ją ponownie podzielić na wiele klas.
źródło
Myślę, że test z takimi zależnościami ( wywoływanie usług internetowych dostawców ) jest raczej testem integracyjnym niż testem jednostkowym.
źródło
Jak powiedzieli inni, jeśli testy jednostkowe mają zewnętrzne zależności, takie jak usługi sieciowe lub wywołania bazy danych, to wcale NIE są to testy jednostkowe, tylko testy integracyjne.
Prawdziwe testy jednostkowe mogą być uruchamiane niezależnie od komponentów zewnętrznych oprócz komponentu, który mają być testowane i powinny być powtarzalne niezależnie od środowiska. Jeśli zewnętrzne usługi internetowe ulegną awarii, test jednostkowy nie powinien zakończyć się niepowodzeniem.
Poradzimy sobie z tym za pomocą Mocking Framework. Pozorowane obiekty pozwalają nam stworzyć próbkę komponentu, dzięki czemu komponent w naszym teście jednostkowym używa tych próbnych obiektów zamiast rzeczywistych. Możemy wstrzykiwać fałszywe obiekty do testowanego komponentu i określać, jakich argumentów oczekujemy, co chcielibyśmy zwrócić w momencie wywołania, a nawet jaki wyjątek chcielibyśmy zgłosić. Zdecydowanie polecam przeczytać więcej na ten temat, ponieważ poprawi to niezawodność i niezależność testów jednostkowych.
Dobry post na temat różnych frameworków C # można znaleźć w następującym wątku SO:
/programming/37359/what-c-mocking-framework-to-use
EDYCJA: W przypadku jawnie wrażliwych posiadam, że nie wspomniałem o DbUnit lub innych narzędziach transakcyjnych, które mogą wycofać zmiany w bazie danych na koniec testu. Są one również powtarzalne i mogą być niezależne od środowiska z wygenerowanymi danymi testowymi, dlatego też Mocking Framework nie jest w tym przypadku potrzebny.
źródło