Czy jest jakaś rzeczywista wartość w jednostce testującej kontroler w ASP.NET MVC?

Mam nadzieję, że to pytanie daje kilka interesujących odpowiedzi, ponieważ jest to pytanie, które mnie trochę denerwowało.

Czy jest jakaś rzeczywista wartość w jednostce testującej kontroler w ASP.NET MVC?

Rozumiem przez to, że przez większość czasu (i nie jestem geniuszem), moje metody kontrolera są, nawet w ich najbardziej skomplikowanych, czymś takim:

public ActionResult Create(MyModel model)
{
    // start error list
    var errors = new List<string>();

    // check model state based on data annotations
    if(ModelState.IsValid)
    {
        // call a service method
        if(this._myService.CreateNew(model, Request.UserHostAddress, ref errors))
        {
            // all is well, data is saved, 
            // so tell the user they are brilliant
            return View("_Success");
        }
    }

    // add errors to model state
    errors.ForEach(e => ModelState.AddModelError("", e));

    // return view
    return View(model);
}

Większość ciężkich zadań jest wykonywana przez potok MVC lub bibliotekę usług.

Być może więc pytania mogą być następujące:

• jaka byłaby wartość jednostki testującej tę metodę?
• czy nie złamać na Request.UserHostAddressi ModelStatez NullReferenceException? Czy powinienem próbować się z nich kpić?
• jeśli zmienię tę metodę w „pomocnika” wielokrotnego użytku (co prawdopodobnie powinienem, biorąc pod uwagę, ile razy to robię!), przetestowałbym to nawet, gdy warto przetestować głównie „potok”, który, przypuszczalnie, czy został przetestowany w ciągu swojego życia przez Microsoft?

Wydaje mi się, że moim celem jest to, że wykonanie poniższych czynności wydaje się całkowicie bezcelowe i niewłaściwe

[TestMethod]
public void Test_Home_Index()
{
    var controller = new HomeController();
    var expected = "Index";
    var actual = ((ViewResult)controller.Index()).ViewName;
    Assert.AreEqual(expected, actual);
}

Oczywiście, że mam obsesję na punkcie tego przesadnie bezcelowego przykładu, ale czy ktoś ma tutaj jakąś mądrość?

Nie mogę się doczekać ... Dzięki.

Nawet dla czegoś tak prostego test jednostkowy będzie służył wielu celom

1. Zaufanie, co zostało napisane, odpowiada oczekiwanemu wynikowi. Sprawdzenie, czy zwraca prawidłowy widok, może wydawać się trywialne, ale wynik jest obiektywnym dowodem na spełnienie wymagania
2. Testy regresji. Jeśli metoda Create wymaga zmiany, nadal masz test jednostkowy dla oczekiwanego wyniku. Tak, dane wyjściowe mogą się zmieniać, co prowadzi do kruchego testu, ale nadal stanowi kontrolę przeciwko niezarządzanej kontroli zmian

W przypadku tej konkretnej czynności przetestuję następujące elementy

1. Co się stanie, jeśli _myService ma wartość NULL?
2. Co się stanie, jeśli _myService.Create zgłosi wyjątek, czy obsłuży określone?
3. Czy pomyślne _myService.Create zwraca widok _Sukces?
4. Czy błędy są propagowane do ModelState?

Zwróciłeś uwagę na sprawdzenie Żądania i Modelu dla NullReferenceException i myślę, że ModelState.IsValid zajmie się obsługą NullReference dla Modelu.

Egzekwowanie wniosku pozwala uchronić się przed żądaniem zerowym, które, jak sądzę, jest generalnie niemożliwe, ale może się zdarzyć podczas testu jednostkowego. W teście integracji pozwoliłby ci podać różne wartości UserHostAddress (Żądanie jest nadal danymi wejściowymi użytkownika, jeśli chodzi o kontrolę i należy je odpowiednio przetestować)

Moje kontrolery są również bardzo małe. Większość „logiki” w kontrolerach jest obsługiwana przy użyciu atrybutów filtru (wbudowanych i odręcznych). Więc mój kontroler zwykle ma tylko kilka zadań:

• Twórz modele z ciągów zapytań HTTP, wartości formularzy itp.
• Wykonaj podstawowe sprawdzenie poprawności
• Zadzwoń do moich danych lub warstwy biznesowej
• Wygeneruj a ActionResult

Większość powiązań modelu jest wykonywana automatycznie przez ASP.NET MVC. DataAnnotations obsługuje także większość sprawdzania poprawności.

Nawet z tak małą ilością do przetestowania, nadal zazwyczaj je piszę. Zasadniczo sprawdzam, czy moje repozytoria są wywoływane i czy ActionResultzwracany jest właściwy typ. Mam wygodną metodę ViewResultsprawdzania, czy zwrócona jest właściwa ścieżka widoku, a model widoku wygląda tak, jak tego oczekuję. Mam inny do sprawdzenia, czy ustawiony jest odpowiedni kontroler / akcja RedirectToActionResult. Mam inne testy JsonResultitp. Itp.

Niefortunnym wynikiem podklasowania Controllerklasy jest to, że zapewnia ona wiele wygodnych metod, które wykorzystują HttpContextwewnętrznie. Utrudnia to jednostkowe przetestowanie kontrolera. Z tego powodu zazwyczaj umieszczam HttpContextwywołania -zależne za interfejsem i przekazuję ten interfejs do konstruktora kontrolera (używam rozszerzenia internetowego Ninject do tworzenia moich kontrolerów). W interfejsie tym zwykle umieszczam właściwości pomocnika w celu uzyskania dostępu do sesji, ustawień konfiguracji, IPrinciple i pomocników URL.

Wymaga to dużej staranności, ale myślę, że warto.

Oczywiście niektóre kontrolery są znacznie bardziej złożone, ale oparte wyłącznie na twoim przykładzie:

Co się stanie, jeśli myService zgłosi wyjątek?

Na marginesie.

Ponadto kwestionowałbym zasadność przekazywania listy przez referencję (nie jest to konieczne, ponieważ c # i tak przechodzi przez referencję, ale nawet jeśli nie była) - przekazywanie akcji errorAction (akcji), którą usługa może następnie wykorzystać do pompowania komunikatów o błędach do które można następnie obsłużyć w dowolny sposób (być może chcesz dodać go do listy, może chcesz dodać błąd modelu, a może chcesz go zalogować).

W twoim przykładzie:

zamiast błędów ref, na przykład do (string s) => ModelState.AddModelError ("", s).