Проводя Приемочное тестирование и следуя BDD, вы утверждаете изменения базы данных или только то, что видит пользователь?

Question

Я делаю приемочное тестирование со Steak в приложении Ruby on Rails.Представьте, что я хочу проверить функциональность формы.

• Он должен создать пользователя, если все поля верны.
• Он не должен создавать пользователя, если какое-либо из полей неверно.

В первом случае сообщение будет информировать о том, что пользователь был создан: «Пользователь создан»

Во втором случае сообщения об ошибках будут указывать ошибки.

Я могу основать мойтесты на отображаемой информации.То есть первый проход теста, если отображается правильное сообщение.

Или я могу основывать свои тесты на изменениях в базе данных.То есть первый тестовый прогон, если в базе данных есть новый пользователь, который содержит введенные данные.

Или я могу утверждать, что для обоих условий база данных должна измениться, и должно отобразиться соответствующее сообщение.

Каков концептуально адекватный способ тестирования такого поведения в соответствии с поведенчески-ориентированной разработкой?

Каков практический способ тестирования такого поведения в соответствии с прагматическим программистом?

Answer 1

Как правило, придерживайтесь того, что видит пользователь.

Однако, иногда есть больше чем один пользователь информации. Возможно, как только данные достигли базы данных, другое приложение затем использует эти данные (довольно типично для внутренних проектов!)

Если вы не можете автоматизировать оба приложения вместе, тогда хорошим решением может стать утверждение содержимого базы данных или проверка ресурсов по URL-адресу RESTful.

Если вы сделаете это, это, вероятно, изменит характер ваших сценариев. Вместо того, чтобы говорить, Then the database should contain XYZ, попробуйте что-то вроде:

Given that Fred Brown lives at 25 Warrington Grove, Springfield
When Fred orders a deckchair
Then the warehouse should receive an order:
    Deckchair
    Quantity: 1
    To: Fred Brown
    25 Warrington Grove
    Springfield

Таким образом, вы всегда смотрите на возможности системы, а не просто на данные - даже если хранилище на самом деле не получает их в вашем сценарии, вы показываете , почему данные имеют быть в этом конкретном месте и форме.

Таким образом, вы также оставляете себе возможность использовать настоящий пользовательский интерфейс или URL-адрес RESTful и т. Д. Позже - этот шаг не зависит от выбранной вами реализации.

Answer 2

Мои практики BDD связаны с использованием огурца. Я стараюсь изо всех сил, чтобы сохранить то, что видит пользователь . То есть любые операторы When и Then должны отражать пользовательский ввод или визуальные эффекты пользователя.

В вашем случае я бы позаботился о том, чтобы впоследствии появилось сообщение об успешном завершении, а затем я бы (если возможно) посмотрел на экране данные, указывающие, что приложение знает об объекте. Например, если вы добавили комментарий к сообщению в блоге, вы должны заполнить его, нажать кнопку «Принять», увидеть сообщение об успешном завершении «Сообщение опубликовано», а затем также увидеть ваш контент на странице в качестве нового сообщения.

Вам следует создать резервные копии пользовательских тестов BDD с помощью модульных, а иногда и контроллеров, чтобы убедиться, что все закулисное функционирование также работает корректно.

Я склонен использовать RSpec и проверять, что что-то добавляется в базу данных, методы возвращают ожидаемые результаты и т. Д. Но я также использую Cucumber, чтобы убедиться, что пользователь видит то, что ожидает его пользователь (но я не очень пусть огурец заботится о том, что в БД).

Надеюсь, это поможет. Если вы еще не используете огурец, я настоятельно рекомендую его для тестирования BDD в сочетании с RSpec. Вы должны проверить книгу (поставляется в электронном виде в формате PDF) - я начал с этого, и это помогло тонна с моей практикой тестирования:

http://www.pragprog.com/titles/achbd/the-rspec-book

Answer 3

Я бы согласился с тем, что видит пользователь, до определенного момента.

Если есть какой-то слой, который потенциально может сохранять значение в памяти, такое, что он может отображаться на сайтекак если бы он был в БД, когда он на самом деле не был записан в БД ... тогда, возможно, было бы неплохо подкрепить ваше «то, что видит пользователь» некоторыми проверками на уровне БД.