Редактировать : я нашел эту статью, только что описывающую концепцию ограниченности в разговоре только о конкретных доменах, чтобы избежать хрупких сценариев .
Его главная мысльчто минимальное количество доменов, о которых вы можете говорить, это проблемный домен и домен решения.Если вы говорите о чем-то за пределами этих двух областей, то вы привлекаете слишком много заинтересованных сторон, вы вносите слишком много шума и делаете свои сценарии хрупкими.
Он также упоминает абсолютную «декларативную» или «императивную» модельбыть мифомОн говорит о когнитивной модели, называемой «чанкинг», говоря, что на любом уровне вашей абстракции вы можете «разбивать» или «разбивать».Это означает, что вы можете получить более явный (как?) Или более мета (что или почему?).Вы отказываетесь от императивной модели, спрашивая "что мы делаем?"Вы говорите "как мы это сделаем?"Так что, думаю, я бы не стал слишком зацикливаться на декларативном и императивном - он никуда не денется, если решит эту проблему.
Что вам поможет, так это выяснение, к каким доменам относится каждый терминВозможно, определив, какая заинтересованная сторона является экспертом для домена, к которому относится этот термин. После того как вы определили все домены, вы можете выбрать связанные термины, которые равны в одном из наиболее выдающихся доменов сценария, илиполностью удалить несоответствующие утверждения.Если этого недостаточно, вы можете разделить, дополнительно указать или переместить сценарий, чтобы он мог удовлетворить эти требования.
Кстати, он также использует сценарий входа в пользовательский интерфейс, поэтому выполучил конкретное руководство:)
Перед редактированием : (часть этого все еще применяется. Вопросы "БД или нет БД" и "UI или нет пользовательского интерфейса" не связаны)
1 - Декларативные или императивные сценарии?
Декларативные, когда это возможно, хотя императив имеет определенную ценность (в некоторые моменты жизненного цикла проекта).
Императив прощеобраз мыслей для тестировщиков и бизнес-аналитиков, не знакомых с теорией и дизайном информации.Об этом также проще подумать ранее в проекте, прежде чем вы приберете проблемный домен и рабочие процессы.Это может быть полезно для исследовательского мышления.
Декларативный характер менее подвержен изменениям с течением времени.Поскольку GUI является частью приложения, наиболее подверженного изменению прихоти, это чрезвычайно ценно.Об этом легче думать, как только вы привели в порядок проблемную область и рабочие процессы и больше сосредоточились на реляционных концепциях.Это более стабильная и более общеприменимая модель.
Если вы пишете тестовые примеры с общей и декларативной моделью, вы можете реализовать их, используя любую комбинацию полной автоматизации графического интерфейса приложения, интеграционных тестов или модульных тестов.
как бы вы описали такие вещи, как «Домашняя страница» или «Страница продуктов»?
Я не уверен, что буду на базовом уровне функций и требований.Вы можете создать подфункции и под-требования, которые описывают детали реализации, например, определенные рабочие процессы пользовательского интерфейса.Если вы описываете часть пользовательского интерфейса, то вы должны определить функцию / требование пользовательского интерфейса.
2 - Упражнение пользовательского интерфейса или нет?
Оба.
Я думаю, что это чрезвычайно медленно и хрупко
Да, это так.Выполняйте все сценарии / требования высокого уровня с помощью пользовательского интерфейса и полной интеграции с БД, но не используйте каждый отдельный путь кода с полной автоматизацией пользовательского интерфейса, и, конечно же, без крайних случаев.Если вы это сделаете, вы потратите больше времени на то, чтобы заставить их работать, и гораздо меньше времени на тестирование вашего приложения.
Вы можете создать архитектуру своего приложения, чтобы проводить более дешевые тесты интеграции,включая цельные тесты на основе пользовательского интерфейса.Модульные тесты также ценны.
Но чем меньше интеграционных тестов вы проводите, тем больше багов по лбу вы пропустите. Может быть проще написать модульные тесты, и они, безусловно, будут менее хрупкими, но по определению вы будете тестировать меньше своего приложения.
3 - Реальная база данных или нет?
Оба.
Сквозные интеграционные тесты высокого уровня должны проводиться с полной системой на месте. Это включает в себя реальную БД, выполнение ваших тестов с каждой системой на разных серверах и т. Д.
Чем ниже уровень, тем больше я защищаю ложные объекты.
- Юнит-тесты должны проверять только отдельные классы
- Интеграционные тесты среднего уровня должны избегать дорогих, хрупких и значимых зависимостей, таких как файловая система, базы данных, сеть и т. Д. Попробуйте проверить реализацию этих хрупких и результативных зависимостей с помощью модульных тестов и сквозных только тесты.