Тестирование устройства против тестов на прием

Ответ 1

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

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

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

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

Ответ 2

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

Нет.

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

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

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

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

Затем вы спорите о сфере работы и следующей версии.

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

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

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

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

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

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

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

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

Ответ 3

Unit Tests - моя конкретная функция делает то, что она должна делать, не более и не менее.

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

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