Turn off your browser and try red, green & refactor pattern (part 1)
· 2 mins read · Testing
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