Каков наилучший способ организации файлов объектов?
Я большой поклонник Specflow и BDD. Это отлично сработало для меня в самых разных проектах.
Одна проблема, которую я еще не решил, - это организация моих файлов и сценариев таким образом, чтобы с ними было легко ориентироваться и исследовать. Представьте, что через год кто-то еще хочет прийти и узнать о системе. Когда начать? Что самое главное, что менее важно? Какие-то отношения между особенностями? Система обрабатывает определенный сценарий? Задумывался ли автор об этой проблеме?
Кто-нибудь может поделиться некоторыми методами, чтениями или инструментами, которые фокусируются на этом?
1 ответ
Этот вопрос на самом деле касается личных предпочтений, но мой ответ заключается в том, как мне сделать мои каталоги более понятными.
С проектами, над которыми я работал, мне приходилось задумываться над такими проблемами, как эта. Я знаю, что в дальнейшем другие люди будут просматривать каталоги огурцов, чтобы добавить больше или сделать различные исправления ошибок.
Вообще говоря, мы взяли этот подход (я буду использовать нашу структуру CucumberJS в качестве примера):
project
| features
| | elements
| | | pages
| | | | home.js
| | | | index.js // grab all of the things in the pages directory
| | | | search.js
| | | index.js // grab everything in elements directory and the index of pages
| | | urls.js
| | | test_customers.js
| | feature_files
| | | home
| | | | homepage_links.feature
| | | | homepage_accessibility.feature
| | | | homepage_check_welsh_translation.feature
| | | search
| | | | search.feature
| | | | search_security.feature
| | step_definitions
| | | common // Won't go into this, but we have a library of reusable steps and functions in here for different projects that we can just port over from git
| | | project
| | | | pages
| | | | | search
| | | | | | search_steps.js
| | | | | | search_security_steps.js
| | | | | home
| | | | | | home_steps.js
| | | | | | home_accessibility_steps.js
| | | | navigation_steps.js
| | | | login_steps.js
| | support
| | | env.js // Timeouts
| | | hooks.js // Setup/Teardown for scenarios
| | | world.js // Setting up the drivers
| reports
| | 2017
| | | 03
| | | | 05
| | | | | report.html
| | | | | report.js
| | | | 06
| | | | | report.html
| | | | | report.js
| | | | 07
| | | | | report.html
| | | | | report.js
| | report.json
| screenshots
| | failed
| | | 2017-03-05
| | | | search_security_xss_204057.png
| | | 2017-03-06
| | | | search_security_xss_100532.png
| | | | search_security_xss_101054.png
| | | | search_security_xss_101615.png
| | search_security
| | | 2017-03-06
| | | | search_security_xss_100528.png
| | | | search_security_xss_101050.png
| | | | search_security_xss_101611.png
| | | | search_security_xss_101841.png
| .gitignore
| README.md
Скажем, вы новичок в проекте, поэтому вы хотите узнать, какие сценарии были написаны. Вы знаете, что это часть набора функций, поэтому вы идете по этому маршруту, вы ищете файл объектов, поэтому вы идете по этому маршруту. Вы интересуетесь тем, как была проверена безопасность для функции поиска, поэтому зайдите туда и найдите файл.
Это та же теория всей остальной структуры папок. Все именно там, где вы и ожидаете.
Это большой вопрос, и я не думаю, что у меня есть прямой ответ, но вот некоторые соображения, которые помогли нам сформировать наши файлы функций. Многое из этого сводится к предпочтениям и конкретным потребностям проекта.
Файлы функций не совпадают с пользовательскими историями.
Из этой превосходной статьи от Мэтта Уинна (автора книги "Огурец"):
Когда Аслак создал Cucumber, он переименовал файлы из.story в.feature. Это был не несчастный случай и не прихоть: просто потому, что есть разница.
Пользовательские истории - это инструмент планирования. Они существуют до тех пор, пока не будут реализованы, а затем исчезают, поглощенные кодом.
Особенности огурца являются средством коммуникации. Они описывают, как система ведет себя сегодня, поэтому, если вам нужно проверить, как она работает, вам не нужно читать код или нажимать кнопки в действующей системе. Организация ваших функций в соответствии с тем, как они были запланированы и реализованы, отвлекает от этой цели.
Написание декларативных файлов объектов, насыщенных бизнес-языком, может сделать ваши сценарии даже более доступными, чем совершенная структура каталогов.
По мере роста вашего проекта (и все больше людей начинают вносить свой вклад) становится все труднее просто перейти непосредственно к местоположению сценария. Следующая лучшая вещь? В поисках этого. Это проще, если ваши сценарии более декларативны и менее обязательны. Из этой статьи от SauceLabs:
Тесты должны быть сосредоточены на том, что должно быть выполнено, а не на деталях того, как это делается. Они должны быть в основном понятными, когда их читают не разработчики.
Самое замечательное в компактных сценариях, написанных на более высоком уровне абстракции, заключается в том, что вы можете поместить больше из них в файл функций, прежде чем он начнет чувствовать себя тесно. Для системных тестов нам повезло соединить высокоуровневого корнишона с шаблоном объекта страницы, потому что он обеспечивает слой для всех этих деталей.
Сценарии и функции легче найти, если они используют тот же бизнес-язык, что и пользовательский интерфейс
Если у вас есть действие "Удалить" в пользовательском интерфейсе, "Удалить" в тесте и "Архивировать" в производственном коде, разработчикам или деловым людям может быть трудно найти сценарии, связанные с этим действием. Возможно, будет легче найти сценарий, если тест всегда следует пользовательскому интерфейсу (если средний член команды, использующий инструмент BDD, лучше знаком с пользовательским интерфейсом, чем с исходным кодом).
Мой способ состоит в том, чтобы организовать по типам пользователей в действиях в конечных точках: приложение / страница, потому что в основном тест состоит в том, чтобы проверить, как каждый покойный API вызывается кем, для чего, где и когда.
Лично мне также нравится Robot Framework вместо Cucumber.