Джо. Иногда я чувствую ту же самую неопределенность. Но я также думаю, что большинство из того, что вам не хватает, - это искренние истории. Во-первых, вы должны немного разложить свою историю, чтобы создать реальные требования разработчиков. Вот что я имею в виду:
"Пользователь должен иметь возможность добавлять виджет, поэтому они должны просматривать детали недавно добавленного виджета."
Хорошо, для меня это дает следующие вопросы, которые помогут вам придумать тесты:
«Пользователь» - откуда он пришел? Как они вошли в систему? (если вы используете AccountController по умолчанию и тесты, то это уже есть, если нет, вам понадобятся тесты для получения формы входа в систему, входа в систему, проверки как успешного, так и неудачного входа в систему и т. д.)
«добавить виджет» - к чему (я не имею в виду реализацию, я просто указываю, что это подразумевает, что вы либо собираетесь использовать репозиторий или сервис, если «добавить» не означает просто добавить его) к работающему экземпляру, и вам не нужно постоянство)? должен ли виджет быть действительным на этом этапе, или недействительные виджеты могут быть сохранены и сделаны действительными позже? Это подразумевает для меня тестирование того, что в репозитории или службе есть метод hit (save (), insert (), add (), что угодно (не внутренняя часть метода), пока вы не приступите к тестированию своей службы / репо, только что контроллер выполняет свою работу, вызывая его), проверьте, что происходит с действительным / недействительным виджетом (вам нужно немного расширить свою историю или добавить историю, чтобы охватить то, что должно происходить с действительными / недействительными виджетами)
«при этом они берутся, чтобы просмотреть детали недавно добавленного виджета» - слегка перефразировано, но в основном то, что вы сказали. Всегда? или только на успехе? Является ли это представление редактируемым или доступным только для чтения (т.е. действие «Изменить» или «Подробности»)? Есть ли сообщение пользователю, в котором говорится, что он был успешным, или он должен сделать вывод из того факта, что он просматривает свой виджет, что он был успешным? Это должно запустить тесты, которые выполняют такие вещи, как проверка свойств в возвращаемом результате действия и проверка значений, хранящихся в TempData (сообщение о состоянии), а также проверка того, что происходит в обоих путях (успех или неудача).
это просто быстрый выстрел, но в основном это мыслительный процесс. вы также можете делать то же самое с другими историями, и в этом отношении генерировать новые истории, чтобы описать поведение приложений.
Пара мыслей о вашем дизайне в будущем.
Ваш следующий тест должен сначала посмотреть на то, что я написал выше, а именно на то, что действие контроллера POST create 1) получит необходимые данные (ваши параметры), 2) вызовет этот сервис / репозиторий, чтобы «добавить» виджет, 3) возможно сделать что-нибудь, если это добавление не удастся (это в вашем дизайне; я дошел до того, что мои контролеры предполагают, что все будет хорошо, и я обрабатываю сбои с помощью атрибутов, но это личное решение проекта), 4) перенаправление на детали .
Итак, ваш следующий тест будет использовать макет (я предпочитаю библиотеку moq для кода Google, но все, что у вас есть, будет работать). Вам понадобится некоторый интерфейс для описания сервиса, который будет вызывать ваш контроллер, и вы передаете имитируемую реализацию этого тестируемому контроллеру, чтобы убедиться, что он вызывает правильный метод. В Moq это выглядело бы примерно так:
[Test]
public void Create_CallsRepository()
{
// Arrange
var currentUser = new User
{
DisplayName = "Fred",
Email = "fred@widgets.com",
Password = "pass",
Status = UserStatus.Active
};
var model = new WidgetModel();
var mockService = new Mock<IService<WidgetModel>();
mockService.Setup(s=>s.Add(model)); //.Returns(whatever) if it returns something
var controller = new WidgetController(mockService.Object);
// Act
var actionResult = controller.Create(currentUser, model);
// Assert
mockService.Verify(s=>s.Add(model));
}
Конечно, это делает некоторые предположения о дизайне, но напряженность в том, как писать свои тесты по сравнению с тем, как ваши объекты должны называться / обрабатывать вещи, является частью того, что делает TDD таким ценным.