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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

Я должен был использовать, тестировать и устанавливать как FitNesse и один из его конкурента, GreenPepper для моей работы, и то, что я могу сказать:

GreenPepper является стечением плагина (слияние является корпоративной викой от Atlassian) и есть много вещей, которые нужны в «предприятии» инструмент уровня с практически без дополнительной работы требуется:

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

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

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