Dlaczego marne jest testowanie widoków MVC?

Obecnie przygotowuję grunt pod aplikację ASP.Net MVC i zastanawiam się, jakie testy jednostkowe powinienem przygotować. Widziałem w wielu miejscach, że ludzie w zasadzie mówią „nie zawracaj sobie głowy testowaniem swoich poglądów, nie ma logiki i jest to trywialne i zostanie objęte testem integracyjnym”.

Nie rozumiem, w jaki sposób stało się to przyjętą mądrością. Testy integracyjne służą zupełnie innym celom niż testy jednostkowe. Jeśli coś popsuję, nie chcę wiedzieć pół godziny później, kiedy kończą się moje testy integracyjne, chcę wiedzieć natychmiast.

Przykładowy scenariusz: Załóżmy, że mamy do czynienia ze standardową aplikacją CRUD z jednostką klienta. Klient ma nazwę i adres. Na każdym poziomie testowania chcę sprawdzić, czy logika pobierania klienta poprawnie pobiera zarówno nazwę, jak i adres.

Aby przeprowadzić test jednostkowy repozytorium, piszę test integracji, aby trafić do bazy danych. Aby przeprowadzić test jednostkowy reguł biznesowych, wyśmiewam repozytorium, wprowadzam odpowiednie reguły biznesowe i sprawdzam, czy oczekiwane wyniki są zwracane.

Co chciałbym zrobić: aby przetestować interfejs użytkownika, kpię z reguł biznesowych, konfiguruję oczekiwaną instancję klienta, renderuję widok i sprawdzam, czy widok zawiera odpowiednie wartości dla określonej instancji.

Co mnie utknęło: Aby przeprowadzić test jednostkowy repozytorium, piszę test integracji, konfiguruję odpowiedni login, tworzę wymagane dane w bazie danych, otwieram przeglądarkę, nawiguję do klienta i sprawdzam, czy wynikowa strona zawiera odpowiednią wartości dla podanej instancji.

Zdaję sobie sprawę, że oba powyższe scenariusze pokrywają się, ale kluczową różnicą jest czas i wysiłek wymagany do skonfigurowania i wykonania testów.

Jeśli ja (lub inny programista) usunę pole adresu z widoku, nie chcę czekać na test integracji, aby to odkryć. Chcę, aby został wykryty i oznaczony w teście jednostkowym, który dostaje się wiele razy dziennie.

Mam wrażenie, że nie rozumiem żadnej kluczowej koncepcji. Czy ktoś może wyjaśnić, dlaczego brak natychmiastowej informacji zwrotnej z testu na temat ważności widoku MVC jest złą rzeczą? (lub jeśli nie jest źle, nie jest to oczekiwany sposób uzyskania opinii)

Proste testowanie interfejsu użytkownika jest dość łatwe w ASP.NET MVC. Zasadniczo wszystko, co musisz zrobić, to upewnić się, że zwrócony kod HTML zawiera potrzebne elementy. Chociaż zapewnia to taką strukturę strony HTML, jakiej oczekujesz, nie w pełni testuje ona interfejs użytkownika.

Prawidłowe testowanie interfejsu internetowego wymaga narzędzia takiego jak Selenium, które będzie korzystało z przeglądarek na twoim komputerze i zapewni, że JavaScript i HTML działają poprawnie we wszystkich przeglądarkach. Selenium ma model klient / serwer, dzięki czemu możesz mieć zestaw maszyn wirtualnych z klientami Unix, Mac i Windows oraz zestaw przeglądarek wspólnych dla tych środowisk.

Teraz dobrze zaprojektowana aplikacja MVC (wzorzec, a nie framework) umieszcza ważną logikę w modelach i kontrolerach. Krótko mówiąc, funkcjonalność aplikacji jest testowana podczas testowania tych dwóch aspektów. Widoki mają zwykle logikę wyświetlania i można je łatwo sprawdzić za pomocą kontroli wzrokowej. Ze względu na cienkie przetwarzanie w widoku i dużą część aplikacji, która została dobrze przetestowana, wiele osób nie sądzi, że ból związany z testowaniem warstwy widoku przeważa nad korzyściami z niej uzyskanymi.

To powiedziawszy, MVC ma kilka fajnych udogodnień do sprawdzenia DOM zwróconego przez żądanie. To znacznie zmniejsza ból podczas testowania warstwy widoku.

Nie powiedziałbym, że to marszczy brwi. Ten sentyment wynika raczej z faktu, że testowanie jednostkowe widoków MVC (przynajmniej odmiany aspx) jest dość trudne, ponieważ widoki aspx mają zbyt dużą zależność od formularzy WebForm, które same są dość niestabilne. Argumentuje więc, że nie warto tego robić, ponieważ poglądy nie są tak skomplikowane.

Oczywiście widoki mogą być dość skomplikowane, więc to twój wybór.

Nie jestem pewien, czy ktoś na to patrzy. Testowalność jest jedną z kluczowych zalet korzystania z ASP.NET MVC. Sprawdź blog Steve Sanderson aby uzyskać więcej informacji na ten temat.

Napisał także praktyczną, najlepszą książkę ASP.MVC (IMO). Nie tylko uczy MVC, ale robi wszystko, aby uczyć najlepszych praktyk, w tym testów.

Myślę, że muszę nieco wyjaśnić widoki testów jednostkowych - możesz budować testy jednostkowe na podstawie wyników zwróconych przez kontroler (ActionResult itp.). Nadal będziesz musiał przeprowadzić inne testy rzeczywistego interfejsu użytkownika i interakcji interfejsu użytkownika.

Możesz dowiedzieć się, jak przetestować widok zwrócony przez akcję kontrolera, jak przetestować widok danych zwrócony przez akcję kontrolera oraz jak sprawdzić, czy jedna akcja kontrolera przekierowuje Cię do drugiej akcji kontrolera, sprawdzając następujący adres URL, opisz w tym krótkim artykule na temat testowania danych w MVC .