В настоящее время я начинаю с BDD - раньше я не писал никаких тестов. Я всегда стараюсь держать свои модели толстыми, а мои контроллеры тощими.Насколько вы проверяете свои контроллеры?
Что вы думаете - нужны ли спецификации контроллера?
С уважением
Да. Проверяйте правильные вызовы и выполняйте правильные переадресации и при необходимости, и проверяйте правильность отображения страниц. Поэтому проверьте, что ваше приложение ведет себя так, как ожидалось.
Для себя я пытаюсь понять баланс между поиском высокого уровня охвата кодом при тестировании и долгосрочной стоимостью поддержки набора тестов, которые могут быть довольно хрупкими.
Предположим, что у нас есть контроллер, который идет
try {
result = mode.doSomething();
if (result.count == 0)
message = "none found"
redisplay criterion page
else if (result.count == 1)
display detail page
else
display list page
} catch exception {
message = "bad things happened, please try again"
redisplay criterion page
}
Предварительная мысль, что испытания трех случаев COUNT (0, 1, много) может быть менее ценным, и более склонны к изменениям, чем испытания дела об исключении. Менее важно, потому что а). другое тестирование будет ловить проблемы на дисплее страницы b). тест очень близок к простому воспроизведению кода.
code: go to page X
test: did you go to page X?
Если разработчик ошибочно выбирает X, он тоже ошибается! Если юзабилити-тестирование пользовательского интерфейса показывает, что Y - лучшая страница для отображения, мы обновляем код и тест в тандеме. Действительно ли тест действительно чего-то добился?
Принимая во внимание, что случай исключения может быть очень сложным в обычном тестировании пользовательского интерфейса, и действительно легко тестировать с помощью mocks. И поведение за исключениями - это то, что нам действительно нужно.
Предполагаю, что вы сначала написали тест для перенаправления на X. Когда вы изменяете, где действие перенаправлено, сначала вы меняете тест, а затем передаете его. Гораздо быстрее проверить это, чем войти в приложение и посмотреть, работает ли он. Даже с огурцом спецификация/тест все еще работает быстрее, чем настройка и сканирование ваших функций. Я твердо убежден в том, что «если вы пишете строку кода, сначала напишите неудачный модульный тест». ОДНАКО, если вы хотите этого избежать, используйте абстракцию наподобие inherited_resources и прекратите писать оба этих кода И. –
Я очень согласен с вами, но на мгновение играю адвоката дьявола. В какой-то момент нам понадобится запустить это приложение, чтобы проверить эстетику, удобство и т. Д. Тогда были отобраны дефекты в перенаправлении. Мы дублируем усилия? Находим ли мы достаточно дефектов, чтобы оправдать усилия?Предположим, что мы нарушили (или даже формально документированную политику) не пишем тестов для трех строк кода, прежде чем мы написали им, насколько велика будет воздействие? – djna
Ручное тестирование может выявить дефекты, но почему тестеры видят материал, который вы можете легко поймать rspec + огурцом? Вы можете легко автоматизировать множество различных тестовых примеров, и вы можете добавлять новые, когда конечный пользователь обнаруживает недостатки. Помните, что эти тесты предназначены не только для создания приложения, но и для последующего его поддержки, особенно если вы хотите сделать обновление фреймворка. –
Что, по вашему мнению, являются необходимыми в спецификации контроллера?
Я не думаю, что они необходимы, если вы их сочетаете с хорошим интеграционным тестом. Я считаю, что удобство использования приложения очень важно, поэтому для каждого изменения в контроллере/представлениях я просматриваю приложение и узнаю, как он себя чувствует. По моему мнению, создание «немых» тестов для контроллеров и представлений не имеет особого значения.
Для тестирования интеграции я использую огурец. Это позволяет протестировать полный стек и убедиться, что приложение работает так, как вы хотите. Для бизнес-логики (модели жира) я все еще использую RSpec.
Многие части визуального поведения я уже тестирую через огурец. – 2009-09-12 10:44:38