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

Question

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

Answer 1

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

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

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

эти два типа тестов не являются взаимозаменяемыми и, как правило, не пересекаются . Таким образом, идея достижения «баланса» между ними не имеет смысла. Вы либо нуждаетесь в них, либо нет.

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

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

Answer 2

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

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

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

Разработчики начинают изнутри и работают наружу, ориентируясь на код:

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

Тестеры начинаются снаружи и работают внутрь, фокусируясь на функциях:

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

Конечные пользователи работают извне и обычно не уделяют большого внимания:

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

Answer 3

Мне нравится Квадрант Брайана Марика на автоматизированных тестах, где различия между бизнесом и технологией сталкиваются и поддерживают программирование против критического продукта.

С этими рамками возникает вопрос о балансе, что мне сейчас нужно?

Answer 4

Однажды я прочитал, что модульный тест - это «Исполняемое требование», что имеет для меня смысл. Если ваш тест не нацелен на доказательство бизнес-требований, тогда он действительно бесполезен. Если у вас есть подробные требования (а это кислотный тест), то вы напишете ряд модульных тестов для реализации каждого возможного сценария, который, в свою очередь, обеспечит целостность ваших алгоритмов и логики структуры данных. Если вы тестируете что-то, что не является обязательным требованием, но вы знаете, что оно должно быть верным для прохождения теста, скорее всего, вы пропустите требования.

Answer 5

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

Answer 6

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

Базовое обоснование выбора приемки по сравнению с модульными тестами такое же, как и базовое обоснование для кода SOLID . Ваша реализация должна быть в состоянии кардинально измениться с помощью рефакторинга и т. Д., Но все бизнес-кейсы - приемочные тесты - должны быть в состоянии остаться неизменными и доказать приемлемое поведение системы (тесты пройдены). В модульных тестах часто существует сильная связь между тестом и кодом реализации. Несмотря на то, что это тестовый код, его все равно следует избегать, и мы должны избегать сильной связи. Выбирая приемочные тесты, вы часто ведете по спирали успеха, создавая хорошо спланированные, расходуемые, не связанные между собой API, позволяющие вашей реализации меняться за кулисами, не заставляя ваши тесты меняться. Кроме того, ваши мысли о реализации разработчика соответствуют мыслям о поведении бизнес-системы. В конце концов я нахожу, что все это лучше для бизнеса и для кодера.

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

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

В приложении, над которым я сейчас работаю, вероятно, есть функциональные тесты с соотношением 10: 1. Модульные тесты работают просто как извлечение сущностей из БД, тесты обработки ошибок для БД / подключения к сети и т. Д. Эти вещи выполняются быстро - минуты или меньше и ежедневно выполняются разработчиками.

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