Добавлю еще опыт. Дело в том, что в 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 для письма (с подсветкой упавшего и пр.).
Нет, Вы ошибаетесь. В том-то и дело, что навык автоматизации не нужен. У нас в проекте тестовые сценарии описаны в Microsoft Test Manageer'е примерно таким образом (то есть предложения вида «пользователь А заходит в систему» и т. д.)
Я не вижу, чем скорость внедрения для старого продукта выше, чем у любого «традиционного» тестового решения. Поясните?
1. Простота
2. Цена
Как Вы знаете, в более-менее забюрократизированной компании часто очень тяжело проходят темы, когда надо попробовать решение, которое надо потом еще и купить. Особенно классно они проходят в outsourse разработке (если мы говорим про компанию — аутсорсера).
И опять-таки, всегда стоит делать поправку на то, что уже применяется в продукте, и кто в нем работает.
Не так уж и много нужно квалификации, чтобы писать простые линейные сценарии на C#.
Сложный вопрос. Здесь проблема в том, что в этом случае также растет и стоимость человека. Ну, если быть точнее, те, кто хотят и могут повысить квалификацию, это уже сделали или как раз работают над этим. И, как результат, довольно скоро им придется платить больше.
Я так и не увидел в вашем тексте никаких достоинств кроме «тестировщик быстро может создавать тестовые сценарии». Что-то еще было, или это единственное?
Да, Вы полностью правы, всего два плюса: скорость внедрения для старого продукта + скорость обучения.
Для API конечно же нужен программист. Без них вообще сложно куда-то уйти, если мы хотим автоматизации (хотя и можно). И на деле задача не в избавлении от программиста, а в том, чтобы тестировщик мог довольно быстро начать создавать тестовые сценарии на чем-то уже готовом. Как Вы понимаете, MsTest для этого не подходит, так как тогда нам уже придется требовать дополнительной квалификации от тестировщиков.
Если у нас есть отдельная команда людей, которые готовы заняться автоматизацией — то тогда, конечно, лучше автоматизацию делать на каком-то языке программирования, так как у всех есть необходимая квалификация, да и возможностей больше. И это не наш случай.
На тему «дополнительного тест раннера» — полностью согласен. В проекты мы автоматически проверяем такие вещи (остальное — руками):
1. Билд всего, что требуется
2. Восстановление базы из схемы
3. Свой статический анализ: тут идут проверки, что модель базы не потеряла индексы, что проекты не ссылаются в bin\Debug и пр.
4. Юнит-тесты (NUnit)
5. FitNesse тесты
Как Вы видите, я похвастаться очень крутым CI. Однако FitNesse помог довольно оперативно внедрить интеграционное тестирование отдельных модулей, и исходя из своего опыта я и перечислил основные достоинства этой технологии (по моему, естественно, мнению).
Довольно сложный вопрос, так как это просто разные подходы. Возможно, корректнее комбинировать их для разных задач. Хотя FitNesse позволяет также работать в стиле «data driven», то есть на вход подается табличка, на выходе проверяем, что колонка заполнена верно.
Более того: важен не подход, а применимость. Изначально были попытки сделать интеграционные тесты с помощью Microsoft Test Manager. Всё провалилось на этапе обучения людей, так как это довольно сложная штука, со своими глюками и ошибками, плюс с богатым функционалом. В результате оказывалось, что быстро начать с ней работать сложно. Ну и добавим стоимость.
С FitNesse основной плюс — это именно легкость написания тестов. В нем есть громадное количество ограничений, например, нет циклов, нет ветвлений. Однако он подходит для выполнения вот таких бизнес требований:
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
И так далее. Вы просто разделяете этот текст на блоки и добавляете в FitNesse. Результирующий тест очень похож на требования. Бизнес аналитик сможет осознать и, возможно, добавить дополнительные шаги в следующем релизе и пр. Ну то есть получаем, что всё предельно просто.
И самое главное: он не исключает возможность создания технических тестов. Некоторые базовые вези тестируются с помощью стандартных Unit Test'ов. Однако продукт покрыт и интеграционными тестами тоже.
Решается данная недоработка просто: 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 для письма (с подсветкой упавшего и пр.).
1. Простота
2. Цена
Как Вы знаете, в более-менее забюрократизированной компании часто очень тяжело проходят темы, когда надо попробовать решение, которое надо потом еще и купить. Особенно классно они проходят в outsourse разработке (если мы говорим про компанию — аутсорсера).
И опять-таки, всегда стоит делать поправку на то, что уже применяется в продукте, и кто в нем работает.
Сложный вопрос. Здесь проблема в том, что в этом случае также растет и стоимость человека. Ну, если быть точнее, те, кто хотят и могут повысить квалификацию, это уже сделали или как раз работают над этим. И, как результат, довольно скоро им придется платить больше.
Да, Вы полностью правы, всего два плюса: скорость внедрения для старого продукта + скорость обучения.
Если у нас есть отдельная команда людей, которые готовы заняться автоматизацией — то тогда, конечно, лучше автоматизацию делать на каком-то языке программирования, так как у всех есть необходимая квалификация, да и возможностей больше. И это не наш случай.
На тему «дополнительного тест раннера» — полностью согласен. В проекты мы автоматически проверяем такие вещи (остальное — руками):
1. Билд всего, что требуется
2. Восстановление базы из схемы
3. Свой статический анализ: тут идут проверки, что модель базы не потеряла индексы, что проекты не ссылаются в bin\Debug и пр.
4. Юнит-тесты (NUnit)
5. FitNesse тесты
Как Вы видите, я похвастаться очень крутым CI. Однако FitNesse помог довольно оперативно внедрить интеграционное тестирование отдельных модулей, и исходя из своего опыта я и перечислил основные достоинства этой технологии (по моему, естественно, мнению).
Более того: важен не подход, а применимость. Изначально были попытки сделать интеграционные тесты с помощью Microsoft Test Manager. Всё провалилось на этапе обучения людей, так как это довольно сложная штука, со своими глюками и ошибками, плюс с богатым функционалом. В результате оказывалось, что быстро начать с ней работать сложно. Ну и добавим стоимость.
С FitNesse основной плюс — это именно легкость написания тестов. В нем есть громадное количество ограничений, например, нет циклов, нет ветвлений. Однако он подходит для выполнения вот таких бизнес требований:
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
И так далее. Вы просто разделяете этот текст на блоки и добавляете в FitNesse. Результирующий тест очень похож на требования. Бизнес аналитик сможет осознать и, возможно, добавить дополнительные шаги в следующем релизе и пр. Ну то есть получаем, что всё предельно просто.
И самое главное: он не исключает возможность создания технических тестов. Некоторые базовые вези тестируются с помощью стандартных Unit Test'ов. Однако продукт покрыт и интеграционными тестами тоже.