Мой интерфейс - приложение на основе EmberJS. Это совершенно асинхронно, поэтому тестирование Capybara - это боль и страдание. С другой стороны, Ember предоставляет фантастический набор тестов из коробки, что делает приемо-сдаточные тесты веселыми и эффективными.
Как правило, либо приспособления, либо бэкенд-издевательства используются для приложений Ember-приемников. Но тестирование против насмешек не удовлетворяет меня вообще:
- Он не будет раскрывать возможные несоответствия API между бэкэнд и интерфейсом, условиями гонки и т.д.
- Таким образом невозможно протестировать бэкэнд-бизнес-логику. Такие тесты не являются интеграционными тестами.
- Наконец, приемочные тесты требуют постоянства, поэтому вам нужно реплицировать бэкэнд-поведение в макете. Это очень утомительно, и вы фактически в конечном итоге реализуете два бэкэнда.
Итак, я хочу протестировать против реального бэкэнда! Тривиально настроить Ember для использования локального экземпляра бэкэнд для тестирования. Но проблема заключается в том, что бэкэнд будет сохранять свое состояние между отдельными тестами и даже сеансами тестирования.
Вот почему я собираюсь внедрить специальный публичный API в Rails:
- API доступен только в том случае, если Rails запущен с определенным флагом или env var.
- Rails запускается в режиме без тестирования, обслуживая обычные вызовы API, как это было бы в процессе производства.
- Перед каждым тестированием внешний интерфейс вызывает специальный API, который указывает Rails, какая настройка базы данных необходима для этого конкретного теста.
- Когда вызов специального API получен, Rails очищает базу данных и заполняет ее запрошенными данными. Например, чтобы удалить элемент из корзины, база данных должна содержать три элемента в корзине.
- Rails завершает запрос API, а интерфейс запускает тест.
- Frontend запускает этапы тестирования, используя обычный интерфейс API, как это было бы в процессе производства: входить в систему, создавать сообщения, комментировать их. Он также попытается сделать некоторые запрещенные вещи, например. г. редактировать сообщения, не войдя в систему, превышать ограничения длины текста и т.д. и проверить, не поддерживает ли бэкэнд запрещенные действия.
- Когда внешний интерфейс запускает следующий тест, он снова вызовет специальный API. Rails сбросит состояние, произведенное предыдущим тестом, и настроит новый для этого конкретного теста.
Я разработчик интерфейса с эскизными знаниями о Rails. Factory Девушка и Очистка базы данных, кажется, являются правильными инструментами для работы, но абсолютно нет информацию о том, как использовать их за пределами обычной тестовой среды Rails. Наверное, мне нужен контроллер или Rails-движок или что-то в этом роде.
Итак, вопрос: как создать API в Rails, который может использоваться интерфейсом для указания Rails для настройки определенного состояния базы данных с помощью прибора factory, тогда как Rails работающий в не-тестовом режиме i. е. обслуживающий REST API и не проходящий через RSpec/Capybara/Cucumber?
Бонусная функция: свойства fixture factory должны быть определены на интерфейсе, чтобы тестовый код хранился в одном месте. Таким образом, бэкэнд должен иметь возможность принимать свойства fixture factory через специальный API. Значения по умолчанию все еще могут быть определены в базовой базе данных.
Я считаю, что это может стать лучшей практикой при принятии/интеграции. Если мне удастся это реализовать, я обещаю опубликовать драгоценный камень.
