What is the flow of using BDD as test-first development approach for front-end and back-end as one project?

Question

Currently I am working on a project using BDD with Cucumber as a test-first development methodology. I am struggling to understand the integration of UI with my back-end code.

As per my understanding BDD->Write failing Scenario (Feature File)->Write Step Definition (Step Def File) ->Application Code (Java Class) I have implemented my back-end using test-first approach (Java cLass). Next, I need to integrate my UI part. Do I need to create my front-end e.g dynamic web project as a separate project and how would that follow test-first way then. Everything on internet is just telling Cucumber and Selenium as automation framework. I couldn't find a good resource on developing a complete end-to-end (even if very small application) but using both front and back as test-first approach.
I don't want to know about testing, I am trying to apply BDD as test-first development approach.

Answer 1

First of all when cuking web applications your initial focus should be on WHAT the application does and WHY its important. So how its implemented is completely irrelevant.

Using Cucumber as a tool to drive development using BDD you just start by writing scenarios guided by WHAT the business wants and WHY the thing they want is so important that they want you to work on it ASAP.

With a UI a user will be doing something (WHAT) and that thing will be important (WHY). The thing they are doing will require an interaction with the UI (at this point HOW they interact is completely irrelevant. This interaction is captured in the scenarios WHEN.

For them to make this interaction some things will have need to have taken place already. These things a captured by the scenarios GIVENS. After the user has interacted with the system something needs to change in the UI. You examine this in the scenarios THENS.

Once you have your scenario you can define and start implementing your step definitions. In general I make each step definition a single call to a helper method, so the steps do only one thing which is to translate a line in a scenario into a call in your programming language.

Now you can define a method in your programming language and only then should you start thinking about HOW you are going to make this all work.

To start this work with a very simple example that you understand. I'll choose registration.

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

now we can do the step definitions, (I'll use ruby, you will have to translate)

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

Now we make our helper methods

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

And thats pretty much it. You just repeat that pattern for every new piece of behaviour you uncover.

Some further tips

most Givens DO NOT need to go through the UI all WHENS interact with the UI all THENS should interact with the UI

what you have done with your backend is totally irrelevant to how you can proceed developing new behaviour with BDD. BDD is all about finding out the WHAT and the WHY. Your backend only becomes relevant when you start thinking about HOW you are going to make the behaviour you have specified work.

If you work in small incremental steps you can use your previous behaviour to build you new behaviour. So once we can register we can start thinking about signing in

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

and we follow exactly the same pattern as above.

Note that because a Given does not have to go through the UI we can do something like

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