Зачем вам писать юнит-тесты для контроллеров?

Для меня это абсолютно неуместный юнит-тест, и я не понимаю, почему кто-то потратил время на его написание, потому что от него очень мало пользы. Я бы прекрасно знал, вернул ли этот контроллер искомый тип, выполнив метод в браузере. В самом деле, вы считаете, что для этого нужен тест и почему?

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() );
    }
}

Ключевой момент здесь:

Я бы прекрасно знал, вернул ли этот контроллер искомый тип, выполнив метод в браузере.

Юнит-тестирование - это автоматизация нерегрессионного тестирования простых блоков кода, а не того, что вы смотрите сами. Вы не хотите делать себе всегда юнит-тестирование в своем приложении.

РЕДАКТИРОВАТЬ: Добавление комментария @anotherdave:

Речь идет о легкости масштабирования. Тестирование одного контроллера в браузере может быть в порядке; как насчет 10, 20, 50 контроллеров? Вы напишите тест один раз; вам может потребоваться обновить его, когда вы меняете контроллер, что накладные расходы. Но как часто вы развертываете? Конечно, ручная проверка каждый раз, когда есть намного больше накладных расходов, чем тест

В качестве альтернативы ответу @ Vladislav , модульное тестирование абсолютно всего может быть излишним, и действительно нежелательным. Если вам нужно что-то более легкое, вы можете провести нерегрессионное тестирование более высокого уровня с помощью Selenium. Конечно, вы получите меньшее покрытие, чем модульное тестирование, но вы можете получить приемлемое покрытие, которое стоит меньше времени на юнит-тестирование и является более гибким.

То есть, если вы все юнит-тестируете, вам нужно обновлять один или несколько тестов каждый раз, когда вы изменяете простой элемент.

Зачем вам писать юнит-тесты для контроллеров?

Потому что, не зная контекста, вы не можете точно сказать, нужно ли вам проверять то или иное. Вот несколько причин, почему вы можете захотеть протестировать контроллеры:

• Контроллер может содержать сложную сервисную логику, которая подвержена ошибкам. Сами сервисы могут работать нормально, это результат, который вы хотите протестировать, и по какой-то причине вы решили не добавлять оркестровочный слой в свое приложение.
• ваши контроллеры содержат ВЕСЬ бизнес-логику приложения, и контроллеры - это фактически все, что вы МОЖЕТЕ протестировать (пожалуйста, не делайте вид, что всю свою жизнь вы работали с идеальными кодовыми базами, такие программы есть, поверьте мне)
• ваша команда состоит из 99% гениев и 1% средних людей, и вы хотите, чтобы этот 1% от ошибок в их зарплате

Я полностью согласен с ОП.

Модульный тест для контроллера не имеет смысла. Вы неявно тестируете свои контроллеры с помощью регрессионных тестов (например, с помощью Selenium).

Вы должны TDD все компоненты / объекты, которые использует контроллер, и поддерживать контроллеры как можно более тонкими. Тогда все правильно проверено модулем. В чем вы хотите убедиться, так это в том, что все хорошо работает вместе при выполнении веб-запросов. Это регрессионное тестирование.