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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

• Улучшенная удобная для пользователя текстура-wiki синтаксис (упрощает работу с для нетехнических людей).
• Он очень хорошо сочетается со многими средства разработки: Eclipse, VB, maven2 и плагин Nant, я тестировал большинство и был очень доволен.
• Пользователь и права доступа управляются слияние, то есть хорошее и сделать использование базы данных вашего likin (который может быть обязательным в зависимости от того, где вы работаете)
• Многие другие функции, которые могут или может не потребоваться: поддержка ssl, удаленное выполнение (установить wiki в unix, выполнить в Windows, если вы работаете над проектом С# или наоборот)
• Выглядит лучше: D

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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