BDD-тестирование REST/JSON-RPC API

Question

Я работаю над проектом, в котором используется смешанный интерфейс REST и JSON-RPC для мобильных приложений. Серверы приложений построены на node.js (express, cluster, pm2) + redis (ioredis) + mysql (node-mysql) + rabbitmq (amqp). Теперь мы сталкиваемся с тяжелым рефакторингом, но тестов нет! Несомненно, это огромная проблема :(

В начале мы планировали покрыть его тестами BDD. Это звучит довольно просто, но есть одно препятствие, подготовка среды до начала тестов. Например, некоторые тесты меняют данные в хранилище, и нам приходится каждый раз перезагружать дамп базы данных. Честно говоря, это крайне неудобно. Более того, держать его в актуальном (обновленном) состоянии непросто, например, когда я меняю код, я должен изменить свалка тоже.

Итак, я заинтересован в способах/инструментах/парадигмах, которые могут быть использованы для получения состояния (содержание) хранения данных (MySQL и Redis).

Спасибо заранее за любого совет

Answer 1

Одна из забавных вещей о шаблоне «Given/When/Then», используемая большинством инструментов BDD, заключается в том, что поведение вызвано «When», а не «Given». Таким образом, не имеет значения, как настроен «данный».

Многие люди используют реальные инструменты для создания данного, но это не обязательно должно быть так.

Вы можете настроить «Дано» с использованием существующих стандартных данных. Например, я могу сказать: «Учитывая статью о кризисе Зики ...» Если вы сейчас работаете над газетным сайтом, у вас будет много статей. Вы можете проверить, чтобы убедиться, что он есть, и даже использовать этот шаг для хранения идентификатора статьи, который вы ожидаете увидеть в следующих шагах. Вы можете настроить некоторые «данные по умолчанию», которые дают вам эту статью. Это нормально проверить, есть ли он, а если нет, сделать один (если он всегда оставляет базу данных в согласованном состоянии для следующих сценариев - не полагайтесь на один сценарий, запускаемый за другим!)

Даже если вы вносите изменения в данные по умолчанию, вы всегда можете сбросить эти изменения в ваших крюках «AfterScenario». JBehave, Cucumber и SpecFlow - все это, as does Cucumber.js.

Если вам нужно каждый раз настраивать что-то другое, попробуйте добавить дату-значение к именам, которые используются. Например, учетная запись не создана г-ном Нортом, она создана г-ном North20160202224400. Таким образом, у вас всегда будут уникальные идентификаторы. Вы можете использовать это в сочетании с крючками «после», чтобы убедиться, что вы тоже правильно очищаете.

Не бойтесь использовать «фоновые» данные, которые могут быть настроены для каждого сценария вместо данных по умолчанию. И помните, что вы можете просто сделать простые вызовы SQL для них; вам не нужно проходить какой-либо пользовательский интерфейс.

Наконец, посмотрите на page object pattern. Он предназначен для репликации поведения веб-страницы и абстрагирования фактических щелчков кнопок, но вы должны иметь возможность видеть параллели между этим и абстрагироваться от поведения, которое создает разные части данных. Мне нравится думать о возможностях: «Что я могу сделать с этой услугой/веб-страницей/API?» Это помогает мне сформировать объект PageObject. Это также поможет вам изолировать поведение создания данных, чтобы при изменении оно менялось только в одном месте.

Без особого контекста трудно понять, какой из этих подходов подходит именно вам, но все эти вещи - подход «Мне все равно» к Givens, фоновым данным, «AfterScenario» и шаблон PageObject - были созданы для решения тех проблем, с которыми вы сталкиваетесь.