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