Рекомендации по применению для спецификации на примере, где аналитики - не разработчики - пишут тесты?

Question

Мы стремимся инициировать подход в стиле bdd, вдохновленный Gojko Adzic's specification by example. Реализация находится в java, и разработчики уже пишут тесты junit.

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

До сих пор я рассматривал FitNesse, Concordion и другие другие (например, Spock). Я отклонил spock и подобные инструменты, потому что они нацеливают разработчиков на основную аудиторию. FitNesse, похоже, удовлетворяет большинству требований.

Конкордион, вероятно, сейчас является фаворитом: характеристики выглядят чище и проще.

Так что мой вопрос (на самом деле три):

1. Любые предложения для других инструментов, которые я должен смотреть?
2. Неужели кому-то удавалось использовать конкордионизм (или другой инструмент) таким образом?
3. Конкордан все еще активно развивается/поддерживается? Трудно сказать с веб-сайта и большинства связанных с ним вопросов - это несколько лет.

Спасибо.

Answer 1

Я работал с рядом команд, реализующих спецификацию по примеру с Concordion. Мы тренируем всю нашу команду, чтобы написать спецификации Concordion в HTML. Требуется только небольшое подмножество HTML, поэтому мы можем обучить новичку примерно через 30 минут. Обычно у нас есть тестеры, которые пишут HTML-спецификацию, причем BA или Scrum Master иногда пишут их.

Мы использовали Eclipse (Редактор веб-страниц) для редактирования HTML. Это хорошо работает, за исключением того, что Concordion требует действительного XHTML, а Eclipse не позволяет проверять HTML как XHTML. Это чаще всего используется с использованием < br> тегов, а не < br />. Мы рассматриваем это на тренировках. Мы также тренируем всю команду в использовании контроля источника. Используя Eclipse, мы имеем один пользовательский интерфейс для редактирования и управления исходным кодом. Мы также обнаруживаем, что наличие команды, использующей ту же IDE, является шагом на пути к кросс-функциональной команде.

Я знаю другую команду, где BA пишет спецификации, используя HTML-редактор на основе Mac.

Конкордион активно поддерживается с быстрыми ответами на список рассылки (Yahoo) и список проблем. Кодовая база Concordion стабильна. Активное развитие за последний год или около того сосредоточилось на механизмах расширения, позволяя пользователям добавлять команды и слушателей (например, для захвата скриншотов при неудаче теста).

Answer 2

Также посмотрите на Cucumber и JBehave, оба из которых позволяют писать спецификации в виде простого текста.

Если вы решите использовать FitNesse, возможно, стоит посмотреть на Slim, который стоит за FitNesse вместо Fit. Он предоставляет несколько разные форматы таблиц для Fit, и я нашел, что он лучше подходит BDD.

Answer 3

Для уточнения темы, вы также можете рассмотреть jnario.