Каков правильный баланс между единицей по сравнению с функциональным тестированием в типичном веб-приложении?

важно различать намерение и объем этих двух типов тестов:

• модульный тест обычно тестирует определенную функцию на уровне модуля/класса, например, создает-X, обновляет-Y, нечто панели, компактное-whizbang, и т.д. Один класс может иметь несколько модульных тестов

• функциональное испытание, также названное 'приемочным испытанием' обычно, тестирует сценарий примера использования от наиболее удаленного интерфейса до конца обработки, например, от пользовательского интерфейса до базы данных и назад снова, от входного процесса до утилиты уведомления, и т.д.

эти два типа тестов не являются interchangable, и являются в целом непересекающимися. Таким образом, понятие устанавливания 'равновесия' между ними не имеет никакого смысла. Вам или нужны они, или Вы не делаете.

если Вы обращаетесь к простоте кодирования каждого типа теста в Вашей среде тестирования, которая является другим вопросом - но использование платформы (говорят, NUnit по сравнению с пользовательским ботом) не изменяет тип/природу теста.

лучший "баланс", в целом, был бы к модульному тесту на уверенность и полноту и функциональное испытание для клиентского принятия

Я соглашаюсь с Steven Lowe, что нет никакого компромисса между поблочным тестированием и функциональным тестированием, поскольку они используются в совсем других целях.

Модульные тесты о методе и вводят проверку и также регрессионное тестирование. Функциональные испытания о функциональном, сценарии и тестировании выполнимости. По-моему, нет почти никакого перекрытия,

Если это помогает, вот мои категории тестирования.

Разработчики запускают с внутренней части и работают за пределы, фокусируясь на коде:

• Утверждения - проверяют поток данных и структуры
• Отладчик - проверяет поток кода и данные
• Поблочное тестирование - проверяет каждую функцию
• Интеграционное тестирование - проверяет подсистемы
• Тестирование системы - проверяет функциональность
• Регрессионные тесты - проверяют, что дефекты остаются фиксированными
• Тесты безопасности - проверяют, что через систему нельзя проникнуть легко.

Тестеры запускают с внешней стороны и работают внутрь, фокусируясь на функциях:

• Приемочные испытания - проверяют требования конечного пользователя
• Тесты сценария - проверяют реальные ситуации
• Глобальные тесты - проверяют выполнимые исходные данные
• Регрессионные тесты - проверяют, что дефекты остаются фиксированными
• Тесты удобства использования - проверяют, что система проста в использовании
• Тесты безопасности - проверяют, что через систему нельзя проникнуть легко
• Покрытие кода - тестирование нетронутого кода
• Совместимость - с предыдущими выпусками
• Поиск причуд и грубых краев.

Конечные пользователи работают с внешней стороны и обычно имеют мало фокуса:

• Приемочные испытания - проверяют требования конечного пользователя
• Тесты сценария - проверяют реальные ситуации
• Тесты удобства использования - проверяют, что система проста в использовании
• Поиск причуд и грубых краев.

На приложении я продолжаю работать в данный момент, существует, вероятно, 10:1 единица к функциональным испытаниям. Работа модульного теста просто вещи как получение объектов от DB, обработка ошибок тестирует на дб/сетевое соединение и т.д. Эти вещи, выполненные быстрый - минуты или меньше и, ежедневно выполняются devs.

функциональные испытания, в то время как меньше склонны быть подходом раковины - могут, пользователь завершить порядок и т.д. склонен покрывать бизнес-доменный конец вещей, выполняются бизнесом analsyts и операциями - печально для нас, часто вручную. Эти вещи занимают недели, чтобы работать и обычно завершать цикл выпуска.

Мой текущий проект приблизительно в 60%-м покрытии модульного теста, и все пользовательские истории имеют покрытие счастливого дня пользовательских историй в тестах селена, у некоторых есть дополнительное покрытие.

Мы постоянно обсуждаем это: Есть ли действительно какая-либо точка требования у покрытия модульного теста все больше абсурдных сценариев для намного более высокого покрытия?

Аргумент - то, что расширение тестов селена увеличивает тестовое покрытие на вещах, которые имеют бизнес-возможность. Клиент действительно заботится об угловых случаях модульного теста, которые могут перестать работать?

Когда Вы становитесь хорошими в тестировании селена, стоимости записи новых тестов с уменьшениями бизнес-возможности. Для нас они так же просты как модульные тесты.

Стоимость во время выполнения является другой проблемой. У нас есть небольшой кластер полей, запускающих эти тесты все время.

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

Тесты должны работать быстро, и справка локализуют проблемы. Модульные тесты позволяют Вам делать это, только тестируя рассматриваемый модуль. Однако функциональная/интеграция/приемочные испытания может быть сделан работать достаточно быстро в большинстве веб-сценариев.

Первоначально я склонился к тяжелому предпочтению модульных тестов по функциональным / приемочным испытаниям из-за начального фактора стоимости приемочных испытаний. Однако со временем я изменил свою философию, и теперь убежденный сторонник выбора приемочных испытаний везде, где возможные и только использующие модульные тесты, когда приемочные испытания не могут удовлетворить мои потребности.

Основное рациональное позади предпочитания принятия по модульным тестам совпадает с основным рациональным для ОСНОВАТЕЛЬНОГО кода. Ваша реализация должна смочь измениться решительно с рефакторингом и т.д., но все экономические модели - приемочные испытания - должны смочь остаться неизменными и доказать приемлемое поведение системы (тестовая передача). С модульными тестами часто существует естественная сильная связь теста к коду реализации. Даже при том, что это - тестовый код, это - все еще код, и сильная связь as-we-know нужно избежать. Путем выбора приемочных испытаний Вы часто ведетесь вниз спираль успеха для создания разрешения хорошо запланированного, потребляемого отделенного API изменению реализации негласно, не вынуждая тесты измениться. Кроме того, Ваши мысли реализации разработчика в гармонии с бизнес-мыслями поведения системы. В конце я нахожу, что все это лучше для бизнеса и для удовлетворенности кодера.

С точки зрения теории я часто спрашиваю меня, если часть кода не может быть протестирована через приемочное испытание, почему та часть кода должна существовать? IE - если это не часть действительного бизнес-сценария, затем это кодирует добавленную стоимость или в настоящее время является этим, и это останется только стоимостью?

Кроме того, если Вы комментируете/документируете свои приемочные испытания хорошо, те комментарии/документы обычно являются актуальнейшим и точным языком системы - который обычно будет позволять Вам избежать других менее ценных подходов документации. Модульные тесты не предоставляют себя той форме общения "бизнес-термина".

Наконец, я не сформировал эту точку наблюдения из просто своей персональной разработки, это оказалось успешным с парой различных проектных групп в моей "очень корпоративной" рабочей среде.

JB http://jb-brown.blogspot.com