Кто-нибудь использует исполняемые требования?

Question

В моем ограниченном опыте работы с ними исполняемые требования (т. Е. Указание всех требований как нарушенных автоматических тестов) оказались удивительно успешными. Я работал над одним проектом, в котором мы уделяли большое внимание созданию высокоуровневых автоматических тестов, которые выполняли бы всю функциональность данного варианта использования / пользовательской истории. Мне было действительно удивительно, насколько легче стало развиваться после того, как мы начали эту практику. Реализация функций стала намного проще после написания теста, и мы смогли внести серьезные архитектурные изменения в систему со всей уверенностью в мире, что все по-прежнему работает так же, как и вчера.

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

Я хотел бы знать 1) есть ли у кого-либо опыт разработки с использованием этого типа определения требований, основанного на тестировании, и 2) какие инструменты вы все использовали для этого.

Answer 1

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

Я пробовал некоторые другие инструменты, включая написание собственного DSL (предметно-ориентированного языка) и использование таких вещей, как RSpec. Мне действительно нравится RSpec, но это, безусловно, больше инструмент для разработчиков, чем для бизнеса.

Я знаю, что Рик Магридж работал над инструментом под названием ZiBreve (http://www.zibreve.com/visit.php?page=index), который должен иметь более сильную поддержку рефакторинга. Я сам не использовал его, но я знаю Рика и говорил с его несколько раз. Я знаю, что на Agile 2008 обсуждалась возможность по-разному справиться с тестами Фитнесса.

Кроме этого, я не видел много хороших инструментов там. Даже такие инструменты, как WinRunner, хороши для тестов типа QA, но для пробного тестирования требований бизнеса, FitNesse или пользовательский DSL, похоже, являются подходящими способами прямо сейчас.

Answer 2

Мне пришлось использовать, протестировать и настроить как фитнес, так и одного из его конкурентов, GreenPepper для моей работы, и я могу сказать:

GreenPepper - это плагин для слияния (confluence - это корпоративная вики от atlassian), в котором есть много всего, что вам нужно в инструменте уровня "предприятия" без дополнительной работы:

• Лучше в использовании синтаксис (облегчает работу с для не технических людей)
• Очень хорошо интегрируется со многими инструменты разработки: Eclipse, VB, Плагин maven2 и Nant, я тестировал большинство и был очень доволен.
• Пользователь и права доступа управляются слияние, то есть это хорошо и использовать базу данных вашего Ликин (что может быть обязательным в зависимости от того, где вы работаете)
• Многие другие функции, которые могут или может не потребоваться: поддержка ssl, удаленное выполнение (установить вики на unix, выполнить на windows, если вы работаете над проектом C #, или наоборот)
• выглядит лучше: D

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

Fitnesse, на мой взгляд, очень простой, очень простой в настройке, он работает, но это все, вы можете использовать некоторые плагины fitnesse, разработанные сообществом открытого исходного кода, и даже некоторые плагины Fit, такие как плагин Eclipse ( собрать каркас прибора из файла теста пригодности, при условии, что он имеет расширение .fit, очень полезно). Интеграция не идеальна, аутентификация и управление правами доступа плохие, но это БЕСПЛАТНО , и если вам что-то нужно, вы можете сделать это, потому что это с открытым исходным кодом.

Answer 3

Возможно, вы захотите взглянуть на Robot Framework (http://robotframework.org).. Он похож на FIT, но, надеюсь, его легче интегрировать в различные инструменты тестирования, контроль версий и непрерывную интеграцию. Различные уровни абстракции в тестовых данных также упрощают его. для обслуживания данных, и когда отдельный редактор тестовых данных становится более зрелым, обслуживание становится еще проще. Краткое руководство по представляет наиболее важные функции инфраструктуры и действует также как исполняемый файл. демо.

Answer 4

Я пробовал Fitnesse и он действительно ужасен (особенно интеграция с SVN). И наша компания разрабатывает аналогичный инструмент с открытым исходным кодом с подходящим движком: FitPro

Другой блестящий инструмент, который я использовал, это Concordion . Единственный недостаток - требования в формате html

Answer 5

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

Answer 6

Мой опыт ограничен личными проектами и обнаружил почти те же преимущества, которые вы упомянули. Я рекомендую http://metacpan.org/pod/Test::Simple::Tutorial, который послужил моим вдохновением для тестирования на основе тестирования. Модули тестирования perl кажутся довольно полезными и гибкими, хотя мне не с чем их сравнивать.

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