В чем преимущество использования фитнес-тестов по сравнению с автоматическими интеграционными тестами?

Тестовые случаи в средах Agile в основном бывают четырех основных типов:

1) Автоматизированные модульные тесты (например, с использованием J-модуля);

2) автоматизированные тесты проверки функций (например, с использованием Fitnesse);

3) автоматические функциональные/регрессионные тесты (например, с использованием Selenium или QuickTestPro);

4) Ручное тестирование.

Для типов 1-3, конечно же, есть заданные автоматизированные тест-кейсы. Для типа 4 тестовые примеры, как правило, являются логическими (или высокоуровневыми) тестовыми наборами, что требует от тестировщиков более высокого уровня навыков и знаний предметной области. Кроме того, имеет место значительное количество тестов, основанных на опыте, таких как исследовательское тестирование, тестирование таксономии дефектов и т. д.

См. блог RBCS здесь:

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

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

Но главное использовать его только в том случае, если вы уверены, что у вас будет много вещей типа бизнес-правил, чтобы убедиться, что BA или даже клиенты могут участвовать в них напрямую. Это не для утверждения, что орбитальная константа вычисляется правильно.

Фитнес должен облегчить бизнес-аналитикам владение тестами и их проведение. Разработчики создают приспособления; бизнес-аналитики передают данные и подтверждают, что тесты пройдены.

По моему опыту, у бизнес-аналитиков нет ни опыта, ни интереса к подобным вещам.

Фитнес-тесты больше похожи на интеграционные тесты. Они могут включать несколько компонентов. Модульные тесты должны выполняться разработчиками на отдельных компонентах. Отсюда и название «единица».

Я предпочитаю модульные тесты.

Вопрос подразумевает ложную дихотомию; FitNesse является автоматизированным решением для интеграционного тестирования. Просто тесты создаются (предназначаются) как разметка на вики-страницах.

В настоящее время я использую его в качестве решения для интеграционного тестирования; Я запускаю все интеграционные тесты, используя командную строку. Тесты также можно запускать через JUnit или REST API (что потребует запуска сервера FitNesse).

Как упоминает Роб в своем ответе, это не (очень) просто настроить и настроить, хотя я тоже не нашел сложно. И я оспариваю заявление Роба о том, что "Это не для утверждения, что орбитальная постоянная вычисляется правильно."; на самом деле, он идеально подходит именно для этого.

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

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