Turn off your browser and try red, green & refactor pattern (part 1)

Trying to debug our code by clicking here and there in the browser is a really common approach that many engineers follow.

The truth is that this is an extremely common and time-consuming pattern. Why I know it? Because I have done it also in the past and to be honest sometimes I am tempted to do it even today. How do I manage to avoid this pitfall?

Turning off the browser is the solution!!

# We still need the browser though

Sure we do. We can use the browser to implement some styling or even replicate a tricky bug and develop a very complex feature. For the rest we can push ourselves to establish a different workflow that will benefit us hugely down the road.

# Work with a plan and not randomly

Before starting working for some new functionality we need to grab a paper and a pencil and write down some thoughts of ours. How are the users going to interact with the UI? What is the role of the components we are going to add? What do we need to achieve with this feature? What services are we going to use and what are the interfaces they are exposing?

Stuff like that are really important, so we can have an end-goal and avoid working blindly.

# Users stories and acceptance criteria

When we are done with such thoughts we can write down some user stories and acceptance criteria, so we can start thinking in detail how the application should behave from the users perspective under circumstances.

Most probably you 'll be given such stories especially if you are working in a team which is following the Agile methodology but it is important to sit down and think about them one more time instead of jumping straight ahead to your IDE.

An example for a simple landing page:

Title: Navigation across website's pages

As a user,
I want to be able to navigate across all website's pages
so that I can access all content and utilities provided

Scenario 1: Visit about page from the home page when using desktop
Given I am on the home page
and I use a desktop browser
when I click the about link
then I should be redirected to the about page

Scenario 2: Return to home page while on about page when using desktop
Given I am on the about page
and I use a desktop browser
when I click the logo
then I should be redirected to the home page

Scenario 3: Visit about page from the home page when using a mobile device
Given I am on the home page
and I use a mobile device
when I click the burger menu link
then I should see the mobile menu
and I click the about link
then I should be redirected to the about page

Scenario 4: Return to home page while on about page when using a mobile device
Given I am on the about page
and I use a mobile device
when I click the logo
then I should be redirected to the home page

As we see, these stories give us a very good idea about the way the application is going to behave after we finish our work. Obviously these should be written before the development process starts and not afterwards else all this is pointless.

We used a very simple language by following the Given/When/Then format which is Gherkin syntax. This is what makes them easy to understand and share with other team members like reviewers and QA engineers or even non-technical people outside of the team.

Details such as screen sizes ranges etc do matter but their importance actually depends on the application itself. So an admin panel might care less about responsiveness while a landing page might follow a mobile-first approach which is pretty reasonable.

# Why do I need these stories?

This part is really important. Because of these, we know exactly how the application should look like when we will finish our work since we have a clear end goal. Don't underestimate this. It plays a vital role. People who have doubts about the end goal they are trying to achieve, most of the times end up working in vain and this is such a huge waste.

With all these acceptance criteria, we can create some test cases and start implementing them by following the red, green and refactor pattern. Let's see what these actually are.

Move on with part 2 here