Каков поток использования BDD в качестве подхода к разработке, ориентированного на тестирование, для внешнего и внутреннего интерфейса как одного проекта?

Прежде всего, при создании веб-приложений ваше первоначальное внимание должно быть сосредоточено на том, ЧТО делает приложение и ПОЧЕМУ оно важно. Так что как это реализовано, совершенно неважно.

Используя Cucumber в качестве инструмента для стимулирования разработки с помощью BDD, вы просто начинаете с написания сценариев, руководствуясь тем, ЧТО хочет бизнес и ПОЧЕМУ то, что они хотят, настолько важно, что они хотят, чтобы вы работали над этим как можно скорее.

С пользовательским интерфейсом пользователь будет что-то делать (ЧТО), и это будет важно (ПОЧЕМУ). То, что они делают, потребует взаимодействия с пользовательским интерфейсом (на данный момент, КАК они взаимодействуют, совершенно не имеет значения. Это взаимодействие фиксируется в сценариях КОГДА.

Чтобы они могли это взаимодействие, некоторые вещи должны уже иметь место. Эти вещи зафиксированы в сценариях ДАННЫХ. После взаимодействия пользователя с системой в пользовательском интерфейсе необходимо что-то изменить. Вы исследуете это в сценариях ТОГДА.

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

Теперь вы можете определить метод на своем языке программирования, и только после этого вы должны начать думать о том, КАК вы собираетесь заставить все это работать.

Чтобы начать эту работу с очень простого примера, который вы понимаете. Я выберу регистрацию.

Scenario: Register
  Given I am a new user
  When I register
  Then I should be registered

теперь мы можем сделать определения шагов (я буду использовать рубин, вам придется переводить)

Given 'I am a new user' do
  @i = create_new_user
end

When 'I register' do
  register(user: @i)
end

Then 'I should be registered' do
  check_registration(user: @i)
end

Теперь делаем наши вспомогательные методы

def create_new_user
  # here you will create a new user. The user will know their email and password
end

def register(user: )
  # here you can use a tool, perhaps selenium, to goto the registration page 
  # and fill in the registration from. You can use the user to get the email,
  # password and any other registration details
end 

def check_registration(user: )
  # here you will look at where you are in the UI and look at the page to
  # confirm the user is registered
end

И это в значительной степени все. Вы просто повторяете этот шаблон для каждой новой части поведения, которую обнаруживаете.

Еще несколько советов

большинству Givens НЕ нужно проходить через пользовательский интерфейс, все КОГДА взаимодействуют с пользовательским интерфейсом, все ТОГДА должны взаимодействовать с пользовательским интерфейсом

то, что вы сделали со своим сервером, совершенно не имеет отношения к тому, как вы можете продолжить разработку нового поведения с помощью BDD. Задача BDD - выяснить, ЧТО и ПОЧЕМУ. Ваш бэкэнд становится актуальным только тогда, когда вы начинаете думать о том, КАК вы собираетесь заставить работать указанное вами поведение.

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

Scenario: Sign in
  Given I am registered
  When I sign in
  Then I should be signed in

и мы следуем точно такому же шаблону, как указано выше.

Обратите внимание: поскольку данный объект не должен проходить через пользовательский интерфейс, мы можем сделать что-то вроде

Given 'I am registered' do
  @i = create_registered_user
end 

def create_registered_user
  user = create_new_user
  save_user_to_db(user)
  return user
end