Czy testowanie jednostkowe jest głównym celem wzoru MVC?

Niedawno w jednym z wywiadów jedno z pytań brzmiało: „Dlaczego korzystamy z MVC?” Właśnie odpowiedziałem, że jest znacznie bliżej tego, jak wiele rzeczywistych systemów jest! Wyjaśniłem zalety, jakie ma, jeśli chodzi o konserwację, skalowalność itp. Nie byli jednak przekonani i ostatecznie powiedzieli mi, że MVC jest używany głównie, ponieważ „umożliwia łatwe testowanie jednostkowe”.

Chociaż wiem, że jest to ważna kwestia, wciąż wątpię, czy jest to główny powód, ponieważ (i) nawet jeśli zdecyduję się nie pisać testów jednostkowych, MVC jest prawdopodobnym wyborem (ii) Wiele systemów GUI, w których istnieją testowe jednostki, nie śledź MVC.

Pytanie brzmi zatem: „Czy testowanie jednostkowe jest głównym celem Wzorca MVC?”

EDYCJA: Zakładam, że mogą wspominać o łatwości testowania / pisania testów NUnit. Wynika to z faktu, że możemy pisać przypadki testowe dla modelu (pod warunkiem, że widok dokładnie odzwierciedla zmiany stanu modelu) - proszę mnie poprawić, jeśli się mylę.

Podstawowym celem byłoby „rozdzielenie obaw”, ponieważ model, pogląd i administrator mają różne obowiązki.

Autor oryginalnego papieru Xerox PARC stwierdza, że:

Podstawowym celem MVC jest wypełnienie luki między modelem mentalnym użytkownika a modelem cyfrowym istniejącym w komputerze.

Gdyby testowanie jednostkowe było głównym celem, można by z łatwością testować widoki jednostkowe. Spojrzenie na krajobraz projektów / ram testów jednostkowych wykazałoby, że jest to całkowicie sprzeczne z przedstawionym twierdzeniem. Zazwyczaj do testowania widoku używa się testów integracyjnych i funkcjonalnych.

Moim zdaniem odpowiedź brzmi zdecydowanie „nie”. Być może była to główna korzyść zaobserwowana w tej konkretnej organizacji, ale nie nazwałbym tego „głównym celem”.

Wydaje mi się, że implementacja MVC nie byłaby taka trudna, to piekielnie trudne do przetestowania w jednostce (cholera - sposób, w jaki to zrobiłem po raz pierwszy, był trudny do przetestowania).

Z drugiej strony można powiedzieć, że prawie każdy wzorzec (wyłączając takie rzeczy jak Singleton) ułatwia testy jednostkowe, ponieważ najczęściej promują one oddzielenie - ale czy jest to ich „główny cel”? Ledwie.

MVC (podobnie jak większość znanych wzorców projektowych) istniało już wcześniej, zanim testy jednostkowe stały się znane. Książka GoF została opublikowana w 1994 r. - dokumentowali oni jedynie wzorce, które były używane od lat (jeśli nie dziesięcioleci) wcześniej. (I nie ma w nim wzmianki o testowaniu jednostkowym.) O testowaniu jednostkowym nie mogę znaleźć dokładnego czasu, kiedy stał się „publiczny” - osobiście czytałem o tym w artykułach związanych z programowaniem ekstremalnym i pierwszej książce XP wyszedł w 1999 roku.

Oczywiście testy jednostkowe nie mogłyby być głównym celem wynalezienia / dokumentowania wzorców - chociaż można uczciwie powiedzieć, że wzorce, gdy są dobrze stosowane, znacznie ułatwiają testowanie jednostkowe.

Myślę, że nie, łatwość testowania jednostek jest jedną z korzyści, ale stanowi część zbioru korzyści przy korzystaniu z MVC wraz z wymienionymi przyczynami. Stwierdzenie, że istnieje jeden główny powód korzystania z MVC, jest błędem. Wygląda na to, że firma, o której mowa, wybiera MVC w celu ułatwienia testów jednostkowych, dlatego uważają, że jest to główny powód. Osobiście moim powodem korzystania z MVC jest jego prostota w porównaniu z formularzami internetowymi, co ułatwia projektowanie i konserwację, ale każda osoba / firma będzie miała swoje własne powody korzystania z dowolnej technologii.

W świecie ASP.NET MVC wiele ulepszeń ASP.NET zostało zawartych w samym frameworku. Głównym celem tego wzorca projektowego jest odizolowanie logiki biznesowej od interfejsu użytkownika, aby skupić się na lepszej konserwacji, poprawie testowalności i czystszej strukturze aplikacji.

ASP.NET MVC ma pewne możliwości, które sprawiają, że jest to najlepsza opcja do wyboru, jeśli potrzebujesz jednej lub więcej z następujących opcji:

• Wysoki poziom kontroli nad generowanym HTML : W przeciwieństwie do formularzy internetowych, widoki w ASP.NET MVC renderują HTML dokładnie tak, jak im każesz. Ostatnio formularze internetowe zostały ulepszone w tym obszarze, ale nadal nie mają poziomu kontroli, jaki ma MVC.

• Łatwiejsze testowanie jednostkowe : dzięki ASP.NET MVC bardzo łatwo jest śledzić wzorce testowe, takie jak programowanie testowe (TDD). Ze względu na złożony cykl życia zdarzeń w formularzach internetowych, oprócz szkieletu opartego na kontroli, TDD jest o wiele łatwiejsze dzięki MVC.

• Rozdzielenie obaw : Odnosi się to do wyraźnego oddzielenia wszystkich aspektów systemu. Ze względu na implementowany wzorzec aplikacja MVC jest podzielona na dyskretne i luźno powiązane części (model, widoki i kontrolery), co ułatwia utrzymanie.

Niektóre inne korzyści to:

• Sam wzorzec MVC ułatwia zarządzanie złożonością poprzez wyraźne rozdzielenie funkcjonalności aplikacji na trzy podstawowe części, model, widok i kontroler.

• Aplikacje internetowe ASP.NET MVC nie używają formularzy stanu ani formularzy opartych na serwerze. To sprawia, że ​​środowisko MVC jest idealne dla programistów, którzy chcą mieć pełną kontrolę nad zachowaniem aplikacji. Stan wyświetlania może stać się bardzo duży, co stanowi problem dla urządzeń takich jak smartfony działające w wolnych sieciach (przesyłanie wszystkich tych informacji może być bardzo wolne). Na stronie formularzy internetowych możesz mieć tylko jedną na stronę. To dość poważne ograniczenie. W MVC nie ma takich ograniczeń - możesz mieć tyle elementów, ile chcesz.

• ASP.NET MVC zapewnia lepszą obsługę programowania opartego na testach (TDD).

• ASP.NET MVC działa dobrze w aplikacjach internetowych obsługiwanych przez duże zespoły programistów i projektantów stron internetowych, które potrzebują wysokiego stopnia kontroli nad HTML. Przetwarzanie żądań ASP.NET MVC