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

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

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

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

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

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

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

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

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

На мой взгляд, Fitnesse очень прост в настройке, он работает, но это все, вы можете использовать некоторые плагины fitnesse, разработанные сообществом open source, и даже некоторые плагины Fit, такие как плагин Eclipse (постройте скелет приспособления из тестового файла fitnesse, при условии, что он имеет расширение .fit, очень полезно). Интеграция не идеальна, аутентификация и управление правами доступа плохи, но это FREE , и если вам что-то нужно, вы можете это сделать, потому что это открытый исходный код.

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

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

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

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

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

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