it-swarm.com.ru

Модульные тесты против приемочных испытаний

Вы для одного или другого? Или оба?

Насколько я понимаю, юнит-тесты:

  • проверить систему с точки зрения разработчика
  • помочь разработчикам практиковать TDD
  • держать код модульным
  • помочь в обнаружении ошибок на низких уровнях детализации

Приемочные испытания:

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

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

Что вы думаете о юнит-тестах и ​​приемочных тестах в целом и как управлять ими по отношению друг к другу?

50
Calvin

Приемочные и интеграционные тесты сообщают вам, работает ли ваш код и завершен ли он; Модульные тесты подскажут, где он терпит неудачу.

Если вы хорошо поработали с приемочными и интеграционными тестами, и они прошли, ваш код реализует все функции, которые он должен, и он работает. Это приятно знать (также приятно знать, что это не так). Но если это не сработает, приемочный тест не даст вам большого понимания того, что пошло не так; так как он тестирует множество функциональных блоков, он может показывать сбой с высоты птичьего полета. Вот где блестят юнит-тесты. Хорошие модульные тесты точно показывают, что пошло не так, и какую именно часть вашего кода. Труднее узнать, написали ли вы достаточно модульных тестов, чем приемочные тесты, но когда у вас есть неудачный приемочный тест без соответствующего неудачного модульного теста - самое время написать этот модульный тест.

Это все с точки зрения тестирования. И, конечно, TDD не (и ATDD) не о тестировании. Что касается управления вашим дизайном, приемочные тесты дают вам широкую дорожную карту ("вот куда вы хотите пойти"), в то время как модульные тесты приводят вас к следующему перекрестку ("поверните налево"). Они оба ценны в этом отношении, и, опять же, их ценность дополняет друг друга.

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

77
Carl Manaster

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

Нет.

Другими словами, пусть последнее [принятие] называет первое [подразделение]. Имеет ли смысл идти в противоположном направлении?

Не беспокойся.

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

Тогда вы спорите о достоверности приемочных испытаний.

Тогда вы спорите о объеме работ и следующем выпуске.

Приемочные испытания, как правило, не являются техническими. Если бы они были, то у вас были бы формальные юнит-тесты, и это было бы так.

Не пытайтесь изощрять политику. Прими это. Позволь этому произойти.


Вы можете надеяться, что разработка, основанная на приемочных тестах (ATDD), приведет к тому, что "приемочные тесты составляются и согласовываются всей командой до начала разработки". Но вы должны отражать реальность того, что все, что написано заранее, в лучшем случае является показным, а в худшем - предметом переговоров.

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

Причиной, лежащей в основе всего первого теста (TDD, ATDD или чего-либо еще), является то, что тест - это железное соглашение. За исключением того, что это не так. С любым методом TDD (или ATDD) вы можете согласиться - в принципе - с тестом результаты, но вы на самом деле не согласились на тест сам по себе.

Может возникнуть так, что тест не может быть легко написан. Или хуже, не может быть написано вообще. Вы можете согласиться с результатами, которые кажутся тестируемыми, но оказываются плохо определенными. Что теперь? Это вещи, которые вы не можете знать, пока не начнете разработку и не разберетесь в деталях.

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

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

11
S.Lott

Модульные тесты - моя конкретная функция делает то, что должна, ни больше, ни меньше.

Acceptance Test - мое приложение делает то, что должно.

Пример: приложение для вычисления корней квадратичных функций. Принимает входы a, b и c, возвращает корни x1 и x2. Это приложение построено на функциях, которые я пишу для сложения двух чисел, вычитания двух чисел, умножения двух чисел, деления двух чисел и получения квадратного корня из двух чисел.

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

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

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

9
iheanyi

Как итог всего вышесказанного,

  • Приемочные тесты убедитесь, что вы строите правильно
  • Модульные тесты позволяют убедиться, что вы строите все правильно
8
tharindu_DG

Это только мое личное мнение по поводу некоторых видов тестов:

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

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

Другими словами, пусть последние называют первое. Имеет ли смысл идти в противоположном направлении?

Я буду осторожен, когда-нибудь соединю их вместе. Модульные тесты представляют собой тесты мельчайших функциональных возможностей, часто настолько маленьких, что конечный пользователь не поймет, что могут быть сотни тестов только для того, чтобы получить веб-форму для ввода данных в систему CRM. Приемочные тесты больше о том, что хочет пользователь приложения, что может быть более субъективным, например. "Это выглядит красиво?" против "Это выглядит правильно?" При приемочных тестах может быть отметка "достаточно хорошо", что я не уверен, что будет работать с юнит-тестами. Как правило, если модульный тест не пройден, кто-то должен решить исправить код или удалить тест, поскольку каждый из них может быть хорошим вариантом в зависимости от обстоятельств.

Что вы думаете о юнит-тестах и ​​приемочных тестах в целом и как управлять ими по отношению друг к другу?

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

2
JB King