Комментарии 29
В чем преимущества описанного вами подхода по сравнению с обычными data-driven-тестами?
Довольно сложный вопрос, так как это просто разные подходы. Возможно, корректнее комбинировать их для разных задач. Хотя FitNesse позволяет также работать в стиле «data driven», то есть на вход подается табличка, на выходе проверяем, что колонка заполнена верно.
Более того: важен не подход, а применимость. Изначально были попытки сделать интеграционные тесты с помощью Microsoft Test Manager. Всё провалилось на этапе обучения людей, так как это довольно сложная штука, со своими глюками и ошибками, плюс с богатым функционалом. В результате оказывалось, что быстро начать с ней работать сложно. Ну и добавим стоимость.
С FitNesse основной плюс — это именно легкость написания тестов. В нем есть громадное количество ограничений, например, нет циклов, нет ветвлений. Однако он подходит для выполнения вот таких бизнес требований:
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
И так далее. Вы просто разделяете этот текст на блоки и добавляете в FitNesse. Результирующий тест очень похож на требования. Бизнес аналитик сможет осознать и, возможно, добавить дополнительные шаги в следующем релизе и пр. Ну то есть получаем, что всё предельно просто.
И самое главное: он не исключает возможность создания технических тестов. Некоторые базовые вези тестируются с помощью стандартных Unit Test'ов. Однако продукт покрыт и интеграционными тестами тоже.
Более того: важен не подход, а применимость. Изначально были попытки сделать интеграционные тесты с помощью Microsoft Test Manager. Всё провалилось на этапе обучения людей, так как это довольно сложная штука, со своими глюками и ошибками, плюс с богатым функционалом. В результате оказывалось, что быстро начать с ней работать сложно. Ну и добавим стоимость.
С FitNesse основной плюс — это именно легкость написания тестов. В нем есть громадное количество ограничений, например, нет циклов, нет ветвлений. Однако он подходит для выполнения вот таких бизнес требований:
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
И так далее. Вы просто разделяете этот текст на блоки и добавляете в FitNesse. Результирующий тест очень похож на требования. Бизнес аналитик сможет осознать и, возможно, добавить дополнительные шаги в следующем релизе и пр. Ну то есть получаем, что всё предельно просто.
И самое главное: он не исключает возможность создания технических тестов. Некоторые базовые вези тестируются с помощью стандартных Unit Test'ов. Однако продукт покрыт и интеграционными тестами тоже.
Понимаете ли, в чем дело, никакой речи о бизнес-аналитике в вашем посте не было. Процитирую еще раз:
Где здесь бизнес-аналитик? Ну и чтобы добавить следующие шаги нужно, чтобы были «функции», а для них нужен программист — замкнутый круг.
Что вам мешает покрывать продукт интеграционными тестами на базе Mstest, или nunit, или xunit — и так далее?
Понимаете ли, в чем дело, фитнес — это дополнительный тест-раннер в решении, для него нужна отдельная настройка, свои тесты, и так далее. Ради чего? Мифического «бизнес-аналитик сможет сам дописать тесты»?
Программист создает функции, тестировщик создает с их помощью тестовый сценарий.
Где здесь бизнес-аналитик? Ну и чтобы добавить следующие шаги нужно, чтобы были «функции», а для них нужен программист — замкнутый круг.
Некоторые базовые вези тестируются с помощью стандартных Unit Test'ов. Однако продукт покрыт и интеграционными тестами тоже.
Что вам мешает покрывать продукт интеграционными тестами на базе Mstest, или nunit, или xunit — и так далее?
Понимаете ли, в чем дело, фитнес — это дополнительный тест-раннер в решении, для него нужна отдельная настройка, свои тесты, и так далее. Ради чего? Мифического «бизнес-аналитик сможет сам дописать тесты»?
Для API конечно же нужен программист. Без них вообще сложно куда-то уйти, если мы хотим автоматизации (хотя и можно). И на деле задача не в избавлении от программиста, а в том, чтобы тестировщик мог довольно быстро начать создавать тестовые сценарии на чем-то уже готовом. Как Вы понимаете, MsTest для этого не подходит, так как тогда нам уже придется требовать дополнительной квалификации от тестировщиков.
Если у нас есть отдельная команда людей, которые готовы заняться автоматизацией — то тогда, конечно, лучше автоматизацию делать на каком-то языке программирования, так как у всех есть необходимая квалификация, да и возможностей больше. И это не наш случай.
На тему «дополнительного тест раннера» — полностью согласен. В проекты мы автоматически проверяем такие вещи (остальное — руками):
1. Билд всего, что требуется
2. Восстановление базы из схемы
3. Свой статический анализ: тут идут проверки, что модель базы не потеряла индексы, что проекты не ссылаются в bin\Debug и пр.
4. Юнит-тесты (NUnit)
5. FitNesse тесты
Как Вы видите, я похвастаться очень крутым CI. Однако FitNesse помог довольно оперативно внедрить интеграционное тестирование отдельных модулей, и исходя из своего опыта я и перечислил основные достоинства этой технологии (по моему, естественно, мнению).
Если у нас есть отдельная команда людей, которые готовы заняться автоматизацией — то тогда, конечно, лучше автоматизацию делать на каком-то языке программирования, так как у всех есть необходимая квалификация, да и возможностей больше. И это не наш случай.
На тему «дополнительного тест раннера» — полностью согласен. В проекты мы автоматически проверяем такие вещи (остальное — руками):
1. Билд всего, что требуется
2. Восстановление базы из схемы
3. Свой статический анализ: тут идут проверки, что модель базы не потеряла индексы, что проекты не ссылаются в bin\Debug и пр.
4. Юнит-тесты (NUnit)
5. FitNesse тесты
Как Вы видите, я похвастаться очень крутым CI. Однако FitNesse помог довольно оперативно внедрить интеграционное тестирование отдельных модулей, и исходя из своего опыта я и перечислил основные достоинства этой технологии (по моему, естественно, мнению).
задача не в избавлении от программиста, а в том, чтобы тестировщик мог довольно быстро начать создавать тестовые сценарии на чем-то уже готовом. Как Вы понимаете, MsTest для этого не подходит, так как тогда нам уже придется требовать дополнительной квалификации от тестировщиков.
Не так уж и много нужно квалификации, чтобы писать простые линейные сценарии на C#.
Как Вы видите, я похвастаться очень крутым CI.
Не. То, что у вас перечислено — это вполне базовые вещи.
Однако FitNesse помог довольно оперативно внедрить интеграционное тестирование отдельных модулей, и исходя из своего опыта я и перечислил основные достоинства этой технологии (по моему, естественно, мнению).
Я так и не увидел в вашем тексте никаких достоинств кроме «тестировщик быстро может создавать тестовые сценарии». Что-то еще было, или это единственное?
Не так уж и много нужно квалификации, чтобы писать простые линейные сценарии на C#.
Сложный вопрос. Здесь проблема в том, что в этом случае также растет и стоимость человека. Ну, если быть точнее, те, кто хотят и могут повысить квалификацию, это уже сделали или как раз работают над этим. И, как результат, довольно скоро им придется платить больше.
Я так и не увидел в вашем тексте никаких достоинств кроме «тестировщик быстро может создавать тестовые сценарии». Что-то еще было, или это единственное?
Да, Вы полностью правы, всего два плюса: скорость внедрения для старого продукта + скорость обучения.
Сложный вопрос. Здесь проблема в том, что в этом случае также растет и стоимость человека. Ну, если быть точнее, те, кто хотят и могут повысить квалификацию, это уже сделали или как раз работают над этим. И, как результат, довольно скоро им придется платить больше.
Так, стоп. Изначально речь шла о тестировщике с навыками автоматизации (иначе он не справится с составлением такого сценария). В моей системе ценностей он уже должен получать достаточно, чтобы не просить еще за навык написания линейных сценариев на C#. Если же речь шла о бизнес-аналитике, то он тем более изначально получает «немножко больше», чем человек, который умеет писать все те же сценарии, так что там этот вопрос тоже не стоит.
Ну и в любом случае, рост стоимости человека — не самая большая проблема (я бы даже сказал, наоборот).
всего два плюса: скорость внедрения для старого продукта + скорость обучения.
Я не вижу, чем скорость внедрения для старого продукта выше, чем у любого «традиционного» тестового решения. Поясните?
Так, стоп. Изначально речь шла о тестировщике с навыками автоматизации (иначе он не справится с составлением такого сценария). В моей системе ценностей он уже должен получать достаточно, чтобы не просить еще за навык написания линейных сценариев на C#. Если же речь шла о бизнес-аналитике, то он тем более изначально получает «немножко больше», чем человек, который умеет писать все те же сценарии, так что там этот вопрос тоже не стоит.
По вашей системе ценностей получается, что топ менеджмент должен уметь в принципе все, начиная от сбора требований и программирования, заканчивая конфигурированием на продакшене :)
Если серьезно, то вот еще плюс (возвращаясь к аналитику:) ) FitNesse позволяет выстраивать коммуникации внутри команды на другом уровне. Когда можно результат выполнения сценария, в одном из самых легко читаемых видов (с описанием всех шагов, с конкретными тестовыми данными, со всем ожиаемыми и реальными результами), переслать тому же разработчику или аналитику для обсуждения — поверьте, это очень удобно.
Про гибкость, открытость, интегрируемость в любые CI процессы и прочее говорить не будем, это, по сути, джентельменский must have.
По вашей системе ценностей получается, что топ менеджмент должен уметь в принципе все, начиная от сбора требований и программирования, заканчивая конфигурированием на продакшене :)
Не, не получается. Не знаю, где это вы вычитали.
Когда можно результат выполнения сценария, в одном из самых легко читаемых видов (с описанием всех шагов, с конкретными тестовыми данными, со всем ожиаемыми и реальными результами), переслать тому же разработчику или аналитику для обсуждения — поверьте, это очень удобно.
Если разработчик и аналитик понимают такую запись сценария, и она подходит для описываемой задачи.
Нет, Вы ошибаетесь. В том-то и дело, что навык автоматизации не нужен. У нас в проекте тестовые сценарии описаны в Microsoft Test Manageer'е примерно таким образом (то есть предложения вида «пользователь А заходит в систему» и т. д.)
1. Простота
2. Цена
Как Вы знаете, в более-менее забюрократизированной компании часто очень тяжело проходят темы, когда надо попробовать решение, которое надо потом еще и купить. Особенно классно они проходят в outsourse разработке (если мы говорим про компанию — аутсорсера).
И опять-таки, всегда стоит делать поправку на то, что уже применяется в продукте, и кто в нем работает.
Я не вижу, чем скорость внедрения для старого продукта выше, чем у любого «традиционного» тестового решения. Поясните?
1. Простота
2. Цена
Как Вы знаете, в более-менее забюрократизированной компании часто очень тяжело проходят темы, когда надо попробовать решение, которое надо потом еще и купить. Особенно классно они проходят в outsourse разработке (если мы говорим про компанию — аутсорсера).
И опять-таки, всегда стоит делать поправку на то, что уже применяется в продукте, и кто в нем работает.
У нас в проекте тестовые сценарии описаны в Microsoft Test Manageer'е примерно таким образом (то есть предложения вида «пользователь А заходит в систему» и т. д.)
Я вам честно скажу: в том виде, в котором у вас тест описан сейчас, он непригоден для автоматизации.
1. Простота
2. Цена
Простота — это в скорость обучения а не внедрения. А цена… MSTest, nUnit, xUnit — бесплатны.
И опять-таки, всегда стоит делать поправку на то, что уже применяется в продукте, и кто в нем работает.
Если мы говорим про скорость внедрения (с нуля в продукте), то это отсутствующий параметр.
FitNesse дает возможность разделить задачи создания тестовых сценариев и их реализацию.
Создание — максимально простое. Любой ручной тестировщк осваивает за пару дней. От разработчика (назовем его эту роль так, это может быть и, собственно, разработчик и автоматизатор), требуется только реализация конкретных шагов.
Из примера выше, разработчик реализует один шаг логина, тестировщики используют в любых сценариях в каких угодно вариантах.
Надо добавить шаг для навигации — ок, тестировщики говорят что нужно, разработчик реализует.
Да, ничего не мешает использовать другие инструменты, но тогда тестовая команда не смжет сама создавать сценарии, их надо будет обучать программировать, делать из них полноценных автоматизаторов. Это далеко не всегда возможно.
Создание — максимально простое. Любой ручной тестировщк осваивает за пару дней. От разработчика (назовем его эту роль так, это может быть и, собственно, разработчик и автоматизатор), требуется только реализация конкретных шагов.
Из примера выше, разработчик реализует один шаг логина, тестировщики используют в любых сценариях в каких угодно вариантах.
Надо добавить шаг для навигации — ок, тестировщики говорят что нужно, разработчик реализует.
Да, ничего не мешает использовать другие инструменты, но тогда тестовая команда не смжет сама создавать сценарии, их надо будет обучать программировать, делать из них полноценных автоматизаторов. Это далеко не всегда возможно.
А можно примеры инструментов data-driven тестирования? Попробуем сравнить на конкретных примерах.
Ниже автор приводит пример бизне требований. На сколько это именно бизнес требования судить не берусь, с моей точки зрения это больше похоже на самый обыкновенный тестовый сценарий. Подойдет такой для примера?
Ниже автор приводит пример бизне требований. На сколько это именно бизнес требования судить не берусь, с моей точки зрения это больше похоже на самый обыкновенный тестовый сценарий. Подойдет такой для примера?
Примерно понимаю о чем вы. Тут такое дело. Кто-то считает, что это DDT, кто-то называет его исключительно BDT инструментом. FitNesse по сути не накладывает никаких ограничений на подход. Мы на практике реализовывали всевозможные варианты тестов, и как-то никогда не думали как их называть :)
Вот примерно такая мешанина, это какой тип теста?
У нас в одном сценарии легко может уживаться предварительная подготовка (в виде вызова нескольких bash скриптов на разных серверах, операции с БД и очистка логов), подготовка тестовых данных (начиная от заливки в БД, заканчивая генерацией файлов по шаблонам), тестовые шаги и проверки (по сути любые и в любых комбинациях, хоть в БД, хоть на файловой системе, хоть WebDriver дергаем) и что-то вроде teardown (все чистим, собираем логи и тд). А может быть и простой тест на одну-две таблицы, но таких тестов генерируется большое кол-во. И если второй пример еще можно назвать DDT, то первый мне сложно как-то однозначно идентифицировать.
ps. Ссылки детальнее посмотрю позднее.
Вот примерно такая мешанина, это какой тип теста?
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
У нас в одном сценарии легко может уживаться предварительная подготовка (в виде вызова нескольких bash скриптов на разных серверах, операции с БД и очистка логов), подготовка тестовых данных (начиная от заливки в БД, заканчивая генерацией файлов по шаблонам), тестовые шаги и проверки (по сути любые и в любых комбинациях, хоть в БД, хоть на файловой системе, хоть WebDriver дергаем) и что-то вроде teardown (все чистим, собираем логи и тд). А может быть и простой тест на одну-две таблицы, но таких тестов генерируется большое кол-во. И если второй пример еще можно назвать DDT, то первый мне сложно как-то однозначно идентифицировать.
ps. Ссылки детальнее посмотрю позднее.
Вот такая мешанина — это мешанина, а не тип теста. Ближе всего это к behaviour-driven.
Если категорично называть вполне себе нормальный тест кейс (да, пусть и не самый маленький, но вполне рабочий для своей задачи) мешаниной, то это путь в холивар за тест дизайн. Здесь же мы обсуждаем инструмент FitNesse, и, как инструмент, он позволяет легко работать с любыми типами тест кейсов не накладывая со своей стороны каких-либо ограничений.
а в чем преимущества перед SpecFlow как для .Net разработчика?
Вики — это конечно интересно, но результаты тестов хочется видеть на билд-сервере относящимся к конкретной версии.
После статьи от FitNesse больше всего отталкивает их собственный запуск тестов, который еще нужно интегрировать с билдами.
Вики — это конечно интересно, но результаты тестов хочется видеть на билд-сервере относящимся к конкретной версии.
После статьи от FitNesse больше всего отталкивает их собственный запуск тестов, который еще нужно интегрировать с билдами.
Про билд-серверы. Есть плагин для Jenkins. Вполне удобный.
Если хочется чего-то своего, то, как писали выше, у FitNesse есть свой RestfulServices с помощью которого можно его запускать в любых вариантах. Выдача может быть xml, txt, html, кому как больше нравится. У нас таким образом FitNesse интегрирован в CruiseControl (Jenkins тоже используем, но меньше). В отчете о билде сразу указываются ссылки на результаты FitNesse тестов которые запускались.
Плюс, сам FitNesse хранит историю выполения тестов, т.е. можно просматритвать и сравнить результаты на любые даты (считай, на любые билды).
Если хочется чего-то своего, то, как писали выше, у FitNesse есть свой RestfulServices с помощью которого можно его запускать в любых вариантах. Выдача может быть xml, txt, html, кому как больше нравится. У нас таким образом FitNesse интегрирован в CruiseControl (Jenkins тоже используем, но меньше). В отчете о билде сразу указываются ссылки на результаты FitNesse тестов которые запускались.
Плюс, сам FitNesse хранит историю выполения тестов, т.е. можно просматритвать и сравнить результаты на любые даты (считай, на любые билды).
Добавлю еще опыт. Дело в том, что в FitNesse есть небольшая особенность: он может потерять тест, если его обновить на файловой системе напрямую (то есть просто поменять файл). Такое не всегда действует, однако мы это стабильно получали из-за того, что тесты хранятся в Source Control. Таким образом, тесты копировались в «главный» FitNesse и запускались из него же (на билд сервере несколько бранчей, хотелось иметь один Web Ui). Ну и при копировании иногда FitNesse терял тесты до следующего запуска, что совсем не круто.
Решается данная недоработка просто: FitNesse можно запустить в режиме «выполнить всё и завершиться». Ну то есть Rest он выполнит сам у себя. Я привел в статье пример, но, чтобы не искать: java.exe -jar «fitnesse-standalone.jar» -d D:\ -c «MyTests?suite&format=xml» -b «d:\builds\TestsResults.xml»
Аргументы:
1. Путь к Jar файлу.
2. -d + путь к папке, в которой лежит fitNesseRoot
3. Наша Rest комманда
4. -b + путь к результирующему xml файлу.
После этого наш CCNet преобразует xml в красивый html для письма (с подсветкой упавшего и пр.).
Решается данная недоработка просто: FitNesse можно запустить в режиме «выполнить всё и завершиться». Ну то есть Rest он выполнит сам у себя. Я привел в статье пример, но, чтобы не искать: java.exe -jar «fitnesse-standalone.jar» -d D:\ -c «MyTests?suite&format=xml» -b «d:\builds\TestsResults.xml»
Аргументы:
1. Путь к Jar файлу.
2. -d + путь к папке, в которой лежит fitNesseRoot
3. Наша Rest комманда
4. -b + путь к результирующему xml файлу.
После этого наш CCNet преобразует xml в красивый html для письма (с подсветкой упавшего и пр.).
С «потерять» не сталкивались. Может особенность Source Control? Привязывали как, через хуки фитнесса на редактирование/обновление или по-своему?
У нас используются различные варианты для контроля ревизий, где то через bash скрипты и cron (малораспространный способ), но в основном через встроенные хуки фитнесса, из коробки вроде с гитом работает, мы написали свой адаптер для свн.
Про копирование: встроенную функцию «зеркалирования» пробовали? Один становится «главным», остальне физически разные экземпляры фитнесса подтягивают изменения с него.
В остальном, да все так :) Запускать можно по всякому, результаты из xml причесываются как кому удобно.
У нас используются различные варианты для контроля ревизий, где то через bash скрипты и cron (малораспространный способ), но в основном через встроенные хуки фитнесса, из коробки вроде с гитом работает, мы написали свой адаптер для свн.
Про копирование: встроенную функцию «зеркалирования» пробовали? Один становится «главным», остальне физически разные экземпляры фитнесса подтягивают изменения с него.
В остальном, да все так :) Запускать можно по всякому, результаты из xml причесываются как кому удобно.
Нет, мы работали напрямую. FitNesse хранит все файлы в виде txt. Ну и мы, соответственно, подменяли txt файлы скриптом. Напрямую. Ну и такой фокус не всегда срабатывал.
Про функцию зеркалирования не знал, огромное спасибо. Изучу.
Про функцию зеркалирования не знал, огромное спасибо. Изучу.
Зеркалирование это я кривовато обозвал. Тут про FitNesse.UserGuide.FitNesseWiki.WikiImport подробно
Про версионность. FitNesse.UserGuide.AdministeringFitNesse.SourceCodeControl. Оказывается CmSystem убрали (то, что использовали мы) теперь, но теперь гит из коробки и VersionsController интерфейс, который выглядит приятнее CmSystem.
Про версионность. FitNesse.UserGuide.AdministeringFitNesse.SourceCodeControl. Оказывается CmSystem убрали (то, что использовали мы) теперь, но теперь гит из коробки и VersionsController интерфейс, который выглядит приятнее CmSystem.
Я посмотрел по диагонали на SpecFlow, если я буду ошибаться — исправьте, пожалуйста. Для .Net разработчика, по моему мнению, преимуществ нет. Так как разработчику проще всего писать тесты в MSTest или в чем-то подобном. Ну так как все знают языки программирования, все умеют программировать, у всех куплена Visual Studio.
С билдами его легко интегрировать: см. соседние комментарии. На создание тестов будет потрачено значительно больше времени, чем на подобную интеграцию.
Преимущество FitNesse в ином: Вы можете разделить разработку самих тестов и создание API. На деле это действительно получается (у нас получалось), ведь тестировщик может использовать еще несуществующие функции при создании тестов (запустить он их не сможет). Допустим, нам нужна функция переименования пользователя. Тестировщик напишет (верстка едет, табличка не получилась..):
|Change user|Some User|
|Property Name|New Value|
|First Name|John|
Тест не запустится — функции-то нет. И создается баг в трекере: требуется функция…. У нас получалось создавать тесты параллельно с API, что довольно круто.
Продолжая сравнение: SpecFlow , как я понял, требует установленной Visual Studio для разработки, тестирования и запуска, верно? А это еще + $1 000 за каждую платформу. Это не большие деньги для компании, но сам факт наличия дополнительных трат может стать серьезной преградой.
Однако если исключить меркантильность и то, что студия кушает больше ресурсов, чем браузер, то получаем, что серьезных преимуществ у FitNesse нет (разве что комьюнити, что не всегда уж и надо). На тему удобства мне сложно что-то говорить, так как я не работал со SpecFlow. Скорее всего, у них есть подсветка кода, выполнение на билд сервере, а не локально (не настраивать же тестировщикам платформы локально?) и всё то, что требуется.
С билдами его легко интегрировать: см. соседние комментарии. На создание тестов будет потрачено значительно больше времени, чем на подобную интеграцию.
Преимущество FitNesse в ином: Вы можете разделить разработку самих тестов и создание API. На деле это действительно получается (у нас получалось), ведь тестировщик может использовать еще несуществующие функции при создании тестов (запустить он их не сможет). Допустим, нам нужна функция переименования пользователя. Тестировщик напишет (верстка едет, табличка не получилась..):
|Change user|Some User|
|Property Name|New Value|
|First Name|John|
Тест не запустится — функции-то нет. И создается баг в трекере: требуется функция…. У нас получалось создавать тесты параллельно с API, что довольно круто.
Продолжая сравнение: SpecFlow , как я понял, требует установленной Visual Studio для разработки, тестирования и запуска, верно? А это еще + $1 000 за каждую платформу. Это не большие деньги для компании, но сам факт наличия дополнительных трат может стать серьезной преградой.
Однако если исключить меркантильность и то, что студия кушает больше ресурсов, чем браузер, то получаем, что серьезных преимуществ у FitNesse нет (разве что комьюнити, что не всегда уж и надо). На тему удобства мне сложно что-то говорить, так как я не работал со SpecFlow. Скорее всего, у них есть подсветка кода, выполнение на билд сервере, а не локально (не настраивать же тестировщикам платформы локально?) и всё то, что требуется.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение FitNesse для .Net приложений