Dlaczego miałbyś pisać testy jednostkowe dla kontrolerów?

Dla mnie jest to całkowicie nieistotny test jednostkowy i nie rozumiem, dlaczego ktoś spędzałby czas na pisaniu go, ponieważ bardzo niewiele można z niego zyskać. Wiedziałbym doskonale, czy ten kontroler zwrócił pożądany typ, wykonując metodę w przeglądarce. Naprawdę, czy uważasz, że do tego potrzebny jest test i dlaczego?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}

Kluczową kwestią jest tutaj:

Wiedziałbym doskonale, czy ten kontroler zwrócił pożądany typ, wykonując metodę w przeglądarce

Tesing jednostek polega na automatyzacji testowania nierejestracyjnego prostych jednostek kodu, a nie na tym, że wyglądasz sam. Nie chcesz robić zawsze jednostkowych modyfikacji w swojej aplikacji.

EDYCJA: Dodawanie komentarza @anotherdave:

Chodzi o łatwość skalowania. Testowanie jednego kontrolera w przeglądarce może być OK; a co z 10, 20, 50 kontrolerami? Raz napiszesz test; konieczne może być zaktualizowanie go po zmianie kontrolera, co jest narzutem. Ale jak często wdrażasz? Z pewnością ręczna kontrola za każdym razem, gdy jest znacznie więcej kosztów ogólnych niż w teście

Jako alternatywa dla odpowiedzi @ Vladislava testowanie jednostkowe absolutnie wszystkiego może być przesadą i naprawdę niepożądane. Jeśli potrzebujesz czegoś lżejszego, możesz przeprowadzić testy regresji wyższego poziomu za pomocą Selenium. Z pewnością uzyskasz mniejszy zasięg niż testy jednostkowe, ale możesz uzyskać raisonable zasięg, który kosztuje o wiele mniej czasu na testowanie jednostkowe i jest bardziej elastyczny.

Oznacza to, że jeśli przetestujesz wszystko, musisz zaktualizować jeden lub więcej testów za każdym razem, gdy modyfikujesz prosty element.

Dlaczego miałbyś pisać testy jednostkowe dla kontrolerów?

Ponieważ bez znajomości kontekstu nie można powiedzieć na pewno, czy trzeba to lub tamto przetestować. Oto kilka powodów, dla których warto przetestować kontrolery:

• kontroler może zawierać złożoną logikę okablowania usługi, która jest podatna na błędy. Same usługi mogą działać dobrze, to wynik, który chcesz przetestować iz jakiegoś powodu zastanawiasz się, czy nie wprowadzić warstwy aranżacji do swojej aplikacji
• twoje kontrolery zawierają CAŁĄ logikę biznesową aplikacji, a kontrolery są właściwie wszystkim, co MOŻESZ przetestować (proszę nie udawaj, że przez całe życie pracowałeś z idealnymi bazami kodów, są takie bazy danych, uwierz mi)
• Twój zespół składa się z 99% geniuszy i 1% przeciętnych ludzi, a Ty chcesz utrzymać ten 1% z błędów w ich pensji

Całkowicie zgadzam się z PO.

Test jednostkowy kontrolera jest bezcelowy. Testujesz swoje kontrolery niejawnie za pomocą testów regresyjnych (na przykład używając Selenium).

Powinieneś TDD wszystkie komponenty / obiekty, których używa kontroler i utrzymywać kontrolery tak cienkie, jak to możliwe. Następnie wszystko jest odpowiednio testowane jednostkowo. Chcesz mieć pewność, że wszystko działa dobrze podczas wykonywania żądań internetowych. To testy regresji.