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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Нет.

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

Не беспокойтесь.

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

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

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

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

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

---

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

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

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

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

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

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

Answer 3

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

Приемочный тест - мое приложение выполняет то, что должно.

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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