Introduction to stubbing and test driven development
Published: 2021-10-22 07:15:59

## Introduction

Suppose you are new to software engineering and wish to dip your toes into software testing. You've implemented the backend lofic of the feature, which also ties to external services and want to test it by writing your test code. You realise after writing a bunch of test code that your feature's core logic does not work and you're not sure whether it's from the logic you wrote or whether the external services that were called failed instead. You scratch your head and realise it's going to be a tough road ahead. 

What can be done differently? What if you wrote your tests before writing your core logic? What if you can abstract the calls to external apis and just focus on checking the core logic you wrote? Well, this can be solved with test driven development as well as stubs. Let me explain what both of these concepts are in detail.

## What is test driven development?

Test Driven Development (TDD) is a software development approach in which test cases are developed to specify and validate what the code will do.  This means that test cases for the functionality is written first before the functionality itself is written to pass the tests. It's key methodology is called "Red, Green, Refactor", which are the 3 phases in TDD.

![Overview of the 3 phases](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nmx20y5lu44swth4hd1l.png)
*Overview of the 3 phases*

### Red

The first phase is writing a test before the functionality. Normally this means writing a test for the happy flow of the functionality. However, as the core logic was not written yet, this test is supposed to fail. This is symbolised by the color red. 

### Green

Now that you have a failing test case, you can focus on getting it to pass. This means implementing your core logic with the singular of focus of passing the test, so disregarding code cleaniness is okay at this juncture. After implementing the code, run the previously written test. If it still fails, determine whether it's the code or the test that is wrong. Subsequently edit your core logic or test code until it passes. This allows you to validate early on in the development process whether the code written works. This phase is symbolised by the color green.

### Refactor

You have a passing test now, congratulations! Now before you create a pull request, make sure to **refactor** the code such that it is clean and neat, removing any additional console logs and unnecessary comments. 

This process can be repeated until all the edge cases for a feature is accounted for and ensures that your feature is well implemented and tested.

## What is stubbing

Now that you undestand the philosophy of TDD, a new question the arises is what if the feature being implemented utilises external APIs? Calling the external API in the test environment, would introduce additional factors that make the test fail such as whether there is a network connectivity issue when calling the external API. This makes it harder to find out which part, ie your code or the external API call, is causing the test to fail. 

Therefore Stubs come into the picture. It is a function or object that replaces the actual behaviour of a module, in the previous call your external API call, with a fixed response. The stub returns the fixed response that you programmed.  Therefore stubs are useful in integration tests where it can mock behaviour with other modules or components, as well as mocking the result when calling external APIs. This reduces additional dependencies that make the test fail and allows you to focus on the core logic being written instead

## Real life applications of stubbing in NodeJS environments.

During a previous software engineering internship, I was working on a NodeJS backend and had to write integration tests.  We used mocha and chai as our Javascript test framework. However, there were times where we used external systems such as firebase or other external APIs in our backend logic. To mock that we used [SinonJS](https://sinonjs.org/) and essentially verify whether specific functions are called, whether errors are thrown as well as what they resolve to. 

## Conclusion

We have gone through a quick introduction on what TDD and stubbing is. I hope this article helps to demystify the 2 concepts and helps you progress in your software engineering journey.

## References

Here are some articles I read and referred to while writing this post, feel free to read more and further expand your knowledge!

- [https://www.guru99.com/test-driven-development.html](https://www.guru99.com/test-driven-development.html)
- [https://www.tutorialspoint.com/software_testing_dictionary/stub.htm](https://www.tutorialspoint.com/software_testing_dictionary/stub.htm)
- [https://openclassrooms.com/en/courses/4554386-enhance-an-existing-app-using-test-driven-development/5095731-understand-the-red-green-refactor-methodology](https://openclassrooms.com/en/courses/4554386-enhance-an-existing-app-using-test-driven-development/5095731-understand-the-red-green-refactor-methodology)
- [https://stackabuse.com/using-stubs-for-testing-in-javascript-with-sinon-js/](https://stackabuse.com/using-stubs-for-testing-in-javascript-with-sinon-js/)