Agile Way: тестирование интеграции или функциональное тестирование или оба?

Question

Я работаю в офисе, который сейчас работает Agile. Мы используем Scrum для управления проектами и смешаемся в технических практиках XP. Он работает хорошо, и мы постоянно изучаем уроки и совершенствуем наш процесс.

Я хотел бы рассказать вам о нашей обычной практике для тестирования и получить обратную связь о том, как это может быть улучшено:

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

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

Функциональное тестирование Мы обычно делаем это структурированным, но ручным способом. Мы играли с Селеном и Ветряной мельницей, которые круты, но для нас, по крайней мере, не совсем там.

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

Answer 1

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

Кроме того, модульное тестирование действительно не проверяет ваш код, особенно если вы практикуете TDD. Процесс TDD helps you design your code better, вы просто получаете дополнительный бонус от набора тестов в конце его.

Вы не указали, работает ли сервер непрерывной интеграции. Я бы настоятельно рекомендовал установить один (Hudson прост в настройке). Затем вы можете выполнить интеграцию и функциональные тесты с каждой проверкой кода.

Answer 2

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

Answer 3

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

Звучит так, будто у вас приличная система. Держите все, если вам нечего терять.

Answer 4

Мы испытали, что сплошной набор тестов на селен фактически подводит итог тому, что клиент ожидает хорошего качества. Итак, в сущности, мы обсуждали этот вопрос: если писать тесты на селен было так же просто, как писать блок-тесты, мы должны меньше сосредоточиться на модульных тестах.

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

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

Answer 5

Я стараюсь не отделять различные варианты тестирования в TDD. Для меня TDD - это Test-Driven Development, а не Unit Test-Driven Development. Поэтому моя практика TDD объединяет модульные тесты, интеграционные тесты, функциональные и приемочные тесты. Это приводит к тому, что некоторые компоненты покрываются определенными типами тестов и другими компонентами, которые подпадают под другие типы тестов очень прагматичным образом.

Я спросил question об актуальности этой практики, а короткий ответ заключался в том, что на практике разделение между быстрыми/простыми тестами запускается автоматически при каждой сборке, а медленные/сложные тесты выполняются реже.

Answer 6

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

Answer 7

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

Сервер сборки настроен с непрерывной интеграцией (CI) в Team Build и для того, чтобы это не сильно забилось медленными тестами (полный тестовый набор занимает более часа для запуска на сервере), мы отделили тесты в «медленные» тесты, которые запускаются дважды в день и «быстрые» тесты, которые запускаются как часть непрерывной интеграции. Установив атрибут тестового метода, сервер сборки может определить разницу между ними.

В целом, «медленные» тесты - это все, что необходимо для доступа к данным, использования веб-сервисов или тому подобного. Они будут рассматриваться как интеграционные тесты или функциональные тесты по общему соглашению. Примерами являются: CRUD-тесты, тесты правил проверки бизнеса, которым нужен набор объектов для работы и т. Д.

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

Я бы рассмотрел любой тест, который выполняется в десятых долях секунды или меньше, чтобы быть «быстрым». Все остальное медленное и, вероятно, не должно выполняться как часть CI.

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

Answer 8

Мне очень нравится концепция Gojko Adzic «теста на сохранение лица», чтобы определить, что вы тестируете через пользовательский интерфейс: http://gojko.net/2007/09/25/effective-user-interface-testing/

Answer 9

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

Answer 10

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