Czy sterowniki w aplikacjach internetowych MVC mogą być testowane w jednostkach?

Question

Wydaje mi się, że twórcy stron internetowych różnych języków programowania często mają różne opinie na ten temat. Na przykład, twórcy stron internetowych Ruby (z Railsami będącymi dominującą strukturą) wydają się myśleć o kontrolerach jako o kodzie kleju, który powinien mieć testy funkcjonalne, ale nie testy jednostkowe. Podobna postawa dominuje w świecie PHP, jednak istnieje pewna inicjatywa (np. Symfony2).

Wygląda jednak na to, że na przykład niektórzy programiści ASP.NET MVC faktycznie mają want their controllersto be unit-testable.

Chciałbym wiedzieć, czy to rzeczywiście działa w tworzeniu stron internetowych. Czy kontrolery warte są testów jednostkowych? Czy projektowanie w testach jednostkowych wyraźnie zmniejsza szybkość programowania w nietrywialnych aplikacjach? Czy masz także jakieś ramy sieciowe, które próbują wymuszać testowalność jednostki kontrolera? Osobiste doświadczenia są mile widziane.

Answer 1

Wszystko, co warte jest przetestowania w jednostce. W tym przypadku zależy to od tego, jaka część logiki jest realizowana w kontrolerach ... W małym projekcie nie można dołączyć żadnej logiki zewnętrznej i możesz chcieć wykonać niektóre operacje bazy danych w kontrolerze (jak na wielu przykładach Microsoftu) . W większych rozwiązaniach może nie być konieczne testowanie kontrolera tak daleko, jak jego zadaniem jest wywoływanie określonych metod logiki biznesowej ... Nie chodzi o to, czy kontrolery są warte testowania jednostkowego, chodzi o to, czy kod, który zawiera, jest ...

Answer 2

Krótka odpowiedź: "Tak" z "Jeśli", długa odpowiedź: "Nie" z "Ale".

W dzisiejszych czasach mam tendencję do opuszczania testów jednostkowych na poziomie kontrolera na rzecz silnego testu jednostkowego zasięgu modeli i obiektów biznesowych oraz pokrycia testu funkcjonalnego z ogórkiem. Założeniem jest tutaj, że kontrolery są bardzo lekkimi obiektami, które kierują dane do podstawowych modeli, które zawierają większość logiki biznesowej.

Jednak nadal mam tendencję do bardzo niewielkiego pokrycia niektórych przepływów sterowania na poziomie kontrolera. Po prostu jest to raczej sprawdzian psychologiczny.

Jednym z problemów z testowaniem na poziomie kontrolera jest to, że często trzeba udawać lub generować dużą liczbę modeli i obiektów, aby móc skutecznie testować. Biorąc to pod uwagę, uważam, że bardziej wartościowe jest przeniesienie tych testów na warstwy funkcjonalne, w których styl testowania pozwala na bardziej wydajne wyrażanie tych zależności (albo przez wyraźne przestrzeganie kroków wymaganych do wygenerowania ich przez samą aplikację lub przez system taki jak Deklaratywne zasady ogórka).

Answer 3

Jedną z najlepszych cech wzorca MVC jest to, że kontrolery mogą być testowane w izolacji wyjścia HTML przez widoki. Strony, które łączą logikę z wyjściami HTML, są trudne do przetestowania i jest to jeden z problemów, który rozwiązuje MVC - to wszystko sprawia, że ​​kontroler jest logiczny i można go przetestować bez parsowania HTML.

Idealnie, twój kontroler pobierze dane z oddzielnych klas dostępu do danych, które możesz zablokować do testów, więc testujesz logikę. Zasadniczo izolujesz kontroler od bazy danych w ten sam sposób, w jaki MVC izoluje go od widoku - wtedy testy są łatwe, ponieważ nie potrzebujesz bazy danych z danymi testowymi.