Спасибо! Расскажите еще, пожалуйста, какие есть варианты это все на прод выкатить? Пусть будет допущение, что у нас простой сайт и мы взяли простой дроплет с nginx и node.js по умлочанию. Что дальше?
Про версионность. FitNesse.UserGuide.AdministeringFitNesse.SourceCodeControl. Оказывается CmSystem убрали (то, что использовали мы) теперь, но теперь гит из коробки и VersionsController интерфейс, который выглядит приятнее CmSystem.
С «потерять» не сталкивались. Может особенность Source Control? Привязывали как, через хуки фитнесса на редактирование/обновление или по-своему?
У нас используются различные варианты для контроля ревизий, где то через bash скрипты и cron (малораспространный способ), но в основном через встроенные хуки фитнесса, из коробки вроде с гитом работает, мы написали свой адаптер для свн.
Про копирование: встроенную функцию «зеркалирования» пробовали? Один становится «главным», остальне физически разные экземпляры фитнесса подтягивают изменения с него.
В остальном, да все так :) Запускать можно по всякому, результаты из xml причесываются как кому удобно.
Про билд-серверы. Есть плагин для Jenkins. Вполне удобный.
Если хочется чего-то своего, то, как писали выше, у FitNesse есть свой RestfulServices с помощью которого можно его запускать в любых вариантах. Выдача может быть xml, txt, html, кому как больше нравится. У нас таким образом FitNesse интегрирован в CruiseControl (Jenkins тоже используем, но меньше). В отчете о билде сразу указываются ссылки на результаты FitNesse тестов которые запускались.
Плюс, сам FitNesse хранит историю выполения тестов, т.е. можно просматритвать и сравнить результаты на любые даты (считай, на любые билды).
Если категорично называть вполне себе нормальный тест кейс (да, пусть и не самый маленький, но вполне рабочий для своей задачи) мешаниной, то это путь в холивар за тест дизайн. Здесь же мы обсуждаем инструмент FitNesse, и, как инструмент, он позволяет легко работать с любыми типами тест кейсов не накладывая со своей стороны каких-либо ограничений.
Если разработчик и аналитик понимают такую запись сценария, и она подходит для описываемой задачи.
На первое если — ответ уверенное «да», отлично понимают.
По второму и, без описания задачи ответить не получится. По опыту, не было тестов, которые не получилось записать в табличной форме.
Примерно понимаю о чем вы. Тут такое дело. Кто-то считает, что это DDT, кто-то называет его исключительно BDT инструментом. FitNesse по сути не накладывает никаких ограничений на подход. Мы на практике реализовывали всевозможные варианты тестов, и как-то никогда не думали как их называть :)
Вот примерно такая мешанина, это какой тип теста?
1. Покупатель заходит в систему…
2.… вводит N данных для покупок.
3. Продавец заходит в систему…
4.… видит, что у него появилась новая задача…
5.… задача содержит вот эти элементы (список)…
6.… продавец делает звонок клиенту (происходит эмуляция)…
7… переводит задачу в отдел доставки
У нас в одном сценарии легко может уживаться предварительная подготовка (в виде вызова нескольких bash скриптов на разных серверах, операции с БД и очистка логов), подготовка тестовых данных (начиная от заливки в БД, заканчивая генерацией файлов по шаблонам), тестовые шаги и проверки (по сути любые и в любых комбинациях, хоть в БД, хоть на файловой системе, хоть WebDriver дергаем) и что-то вроде teardown (все чистим, собираем логи и тд). А может быть и простой тест на одну-две таблицы, но таких тестов генерируется большое кол-во. И если второй пример еще можно назвать DDT, то первый мне сложно как-то однозначно идентифицировать.
Так, стоп. Изначально речь шла о тестировщике с навыками автоматизации (иначе он не справится с составлением такого сценария). В моей системе ценностей он уже должен получать достаточно, чтобы не просить еще за навык написания линейных сценариев на C#. Если же речь шла о бизнес-аналитике, то он тем более изначально получает «немножко больше», чем человек, который умеет писать все те же сценарии, так что там этот вопрос тоже не стоит.
По вашей системе ценностей получается, что топ менеджмент должен уметь в принципе все, начиная от сбора требований и программирования, заканчивая конфигурированием на продакшене :)
Если серьезно, то вот еще плюс (возвращаясь к аналитику:) ) FitNesse позволяет выстраивать коммуникации внутри команды на другом уровне. Когда можно результат выполнения сценария, в одном из самых легко читаемых видов (с описанием всех шагов, с конкретными тестовыми данными, со всем ожиаемыми и реальными результами), переслать тому же разработчику или аналитику для обсуждения — поверьте, это очень удобно.
Про гибкость, открытость, интегрируемость в любые CI процессы и прочее говорить не будем, это, по сути, джентельменский must have.
FitNesse дает возможность разделить задачи создания тестовых сценариев и их реализацию.
Создание — максимально простое. Любой ручной тестировщк осваивает за пару дней. От разработчика (назовем его эту роль так, это может быть и, собственно, разработчик и автоматизатор), требуется только реализация конкретных шагов.
Из примера выше, разработчик реализует один шаг логина, тестировщики используют в любых сценариях в каких угодно вариантах.
Надо добавить шаг для навигации — ок, тестировщики говорят что нужно, разработчик реализует.
Да, ничего не мешает использовать другие инструменты, но тогда тестовая команда не смжет сама создавать сценарии, их надо будет обучать программировать, делать из них полноценных автоматизаторов. Это далеко не всегда возможно.
А можно примеры инструментов data-driven тестирования? Попробуем сравнить на конкретных примерах.
Ниже автор приводит пример бизне требований. На сколько это именно бизнес требования судить не берусь, с моей точки зрения это больше похоже на самый обыкновенный тестовый сценарий. Подойдет такой для примера?
Спасибо, принимается :) про то, что одну лишь цель преследует — некорректно.
Но согласитесь, что если принимать во внимание физическое воздействие холодной воды, то понижение температуры приводит к остановке процесса варки в самих макаронах.
Про итальянские: я все-таки думаю, что тут надо еще вспомнить и про «аль денте». Например, спагетти, которые если слегка не доварить намного интереснее на вкус.
Промыть макароны холодной водой преследует одну лишь простую цель: остановить процесс варки. То, что потом макароны меньше слипаются — это уже следствие.
перейдя по сслыке, а что за фотография справа вверху?
может ссылкой сделаете, чтобы просто интересующимся моно было и дальше покопать, кто придумал/провел первый такую реакцию (если мои догадки верны)?
Спасибо за пример с получением токена в два запрос. Документация явно этот момент не раскрывает ?
Про версионность. FitNesse.UserGuide.AdministeringFitNesse.SourceCodeControl. Оказывается CmSystem убрали (то, что использовали мы) теперь, но теперь гит из коробки и VersionsController интерфейс, который выглядит приятнее CmSystem.
У нас используются различные варианты для контроля ревизий, где то через bash скрипты и cron (малораспространный способ), но в основном через встроенные хуки фитнесса, из коробки вроде с гитом работает, мы написали свой адаптер для свн.
Про копирование: встроенную функцию «зеркалирования» пробовали? Один становится «главным», остальне физически разные экземпляры фитнесса подтягивают изменения с него.
В остальном, да все так :) Запускать можно по всякому, результаты из xml причесываются как кому удобно.
Если хочется чего-то своего, то, как писали выше, у FitNesse есть свой RestfulServices с помощью которого можно его запускать в любых вариантах. Выдача может быть xml, txt, html, кому как больше нравится. У нас таким образом FitNesse интегрирован в CruiseControl (Jenkins тоже используем, но меньше). В отчете о билде сразу указываются ссылки на результаты FitNesse тестов которые запускались.
Плюс, сам FitNesse хранит историю выполения тестов, т.е. можно просматритвать и сравнить результаты на любые даты (считай, на любые билды).
На первое если — ответ уверенное «да», отлично понимают.
По второму и, без описания задачи ответить не получится. По опыту, не было тестов, которые не получилось записать в табличной форме.
Вот примерно такая мешанина, это какой тип теста?
У нас в одном сценарии легко может уживаться предварительная подготовка (в виде вызова нескольких bash скриптов на разных серверах, операции с БД и очистка логов), подготовка тестовых данных (начиная от заливки в БД, заканчивая генерацией файлов по шаблонам), тестовые шаги и проверки (по сути любые и в любых комбинациях, хоть в БД, хоть на файловой системе, хоть WebDriver дергаем) и что-то вроде teardown (все чистим, собираем логи и тд). А может быть и простой тест на одну-две таблицы, но таких тестов генерируется большое кол-во. И если второй пример еще можно назвать DDT, то первый мне сложно как-то однозначно идентифицировать.
ps. Ссылки детальнее посмотрю позднее.
По вашей системе ценностей получается, что топ менеджмент должен уметь в принципе все, начиная от сбора требований и программирования, заканчивая конфигурированием на продакшене :)
Если серьезно, то вот еще плюс (возвращаясь к аналитику:) ) FitNesse позволяет выстраивать коммуникации внутри команды на другом уровне. Когда можно результат выполнения сценария, в одном из самых легко читаемых видов (с описанием всех шагов, с конкретными тестовыми данными, со всем ожиаемыми и реальными результами), переслать тому же разработчику или аналитику для обсуждения — поверьте, это очень удобно.
Про гибкость, открытость, интегрируемость в любые CI процессы и прочее говорить не будем, это, по сути, джентельменский must have.
Создание — максимально простое. Любой ручной тестировщк осваивает за пару дней. От разработчика (назовем его эту роль так, это может быть и, собственно, разработчик и автоматизатор), требуется только реализация конкретных шагов.
Из примера выше, разработчик реализует один шаг логина, тестировщики используют в любых сценариях в каких угодно вариантах.
Надо добавить шаг для навигации — ок, тестировщики говорят что нужно, разработчик реализует.
Да, ничего не мешает использовать другие инструменты, но тогда тестовая команда не смжет сама создавать сценарии, их надо будет обучать программировать, делать из них полноценных автоматизаторов. Это далеко не всегда возможно.
Ниже автор приводит пример бизне требований. На сколько это именно бизнес требования судить не берусь, с моей точки зрения это больше похоже на самый обыкновенный тестовый сценарий. Подойдет такой для примера?
Sikuli SikuliWebDriver
Но согласитесь, что если принимать во внимание физическое воздействие холодной воды, то понижение температуры приводит к остановке процесса варки в самих макаронах.
Про итальянские: я все-таки думаю, что тут надо еще вспомнить и про «аль денте». Например, спагетти, которые если слегка не доварить намного интереснее на вкус.
Не увидел статического анализа кода, например PMD.
может ссылкой сделаете, чтобы просто интересующимся моно было и дальше покопать, кто придумал/провел первый такую реакцию (если мои догадки верны)?