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

We could continue by repeating the same pattern again and again until we fulfill all stories and acceptance criteria. Then we can open our browser and focus on the styling some more. The core functionality is already in place without any random clicks in the UI while we managed to establish a pretty structured plan right from the very start.

# Is this approach time-consuming?

So this is something that inexperienced people with testing tend to ask a lot. Am I going to lose time? Is this time consuming? What if there is a deadline? Should I take some shortcuts?

All these make sense but mostly if you consider tests to be an additional burden you should deal with after you finish with the core functionality.

As you get, the approach we followed above takes it the other way around so that tests are used to help us design and implement the actual feature in steps. It is not an extra burden or a bottleneck that delays us in the end. Testing is actually part of our workflow with BDD pattern and not an additional phase that takes some extra time.

We need to think differently and change our mindset in order to make this work. For sure the risk of building something useless and non-functional is reduced by far by following this workflow.

Last but not least, with this approach we reduce Quality Assurance testing by far since we deliver something well-prepared and robust while other engineers can build easier on top of it, since all these test cases are in place for further usage.

All these mean that we increase the business value of the code we ship to production which is a really important factor in the lifecycle of a product because stability, maintainability and extendability play a huge role in its success. Cheers!!

Did you miss part 3? You can find it here

In case you want to take it from the very start, check part 1 here