Explaining Test Driven Development (TDD) Part 3: A Real Example Using NodeJS
Now that you understand what TDD is and how the TDD cycle works, here, in part 3, I will outline an example of TDD using NodeJS. I will begin by setting up the dependencies, then creating the project and, finally, I will show you actual code using NodeJS.
Set up dependencies
It is time to apply the concept of TDD in an app using Node JS. For the purposes of this exercise, let’s use the same calculator example outlined in part 2. We are going to use the following technologies:
This example makes the following assumptions:
- NodeJs installed, refer to this link if you do not have it.
- Knowledge about testing (Pretty basic, you do not need to be an expert). Specifically, those concepts I outlined in part 1 and part 2 in my previous posts.
- Basic knowledge about NodeJs
To begin, the first step is to install Mocha. Mocha is a test framework used in NodeJs projects. This step is really easy. You simply run an npm command in the terminal:
$ npm install -g mocha
Now, we need Chai in our project. Chai works as our assertion library. To install Chai, run in the terminal:
$ npm install chai —save–dev
(In this last step, we are installing development dependencies. That is the reason for the parameter –dev)
Creating the NodeJS project
For the purposes of this example, we are going to work with an ExpressJs project. We can use Express Generator in order to create a base project. Let’s run the following in the terminal:
$ express tdd_test
Then install dependencies:
$ npm install
The first thing you can do in order to facilitate the process is to modify your package.json. Let’s modify the “test” script. What you need now is to find the section of scripts and add the following:
“scripts”: {
“start”: “node ./bin/www”,
“test”: “mocha test”
},
Now, each time that we use the command npm test, it will automatically call mocha.
Coding…
You need to create a test folder in the root of the project. By default, mocha looks inside a “test” folder for test classes. Also, you can point the route of your tests, but for the purposes of this example, let’s use the default one. Inside that folder, let’s create a file called “index.test.js”. This will work as primary class for our test.
Now that we have all the structure ready, let’s apply the cycle of TDD that you learned about in part 1 and part 2 of my posts:
1. Write a test for a desired feature.
In the folder called test, create a subfolder called “controllers”. Here, we will store all of our controller tests. Then, create a file called “controller.test.js”. Remember, as I stated above, our purpose is to create a test that evaluates an “add” function. Therefore, we should create all the logic for that test. If you remember from my previous post, the logic is as follows: “Given two numbers, it should return the correct result for that operation”.
Basically, we are importing our test library (chai) and then the module of the feature that we will create soon in the next step. Then, in the test, we are passing two numbers to our “add” function and we expect that the result will be “3”. So far, we have not created any code for our feature, just the test.
2. Run that test and watch how it fails!
So far we have not created any code for our feature, just the test. If we run the command to test:
$ npm test
It definitely will fail, showing something like this in the console:
Do not be afraid, it is totally normal! The error is telling us that “addOp” is not a function, because we have not created the function yet.
3. Implement the feature (Just the structure, no logic yet).
Here we need to create the declaration of the function, not more, just the header declaration. In order to do this, let’s create a folder called “controller” in our root folder. Then, create a file called “operations.js” and declare the function, like this:
We have declared just the header, not logic yet. That means that now we are able to import that function and pass it two variables, but it will not do anything because there is no logic declared.
4. Run the test and watch how it fails again!
Let’s run the test command again:
$ npm test
And watch how it fails! You should be able to see something like this in the console:
5. Implement the logic, syntax, etc.
In this step, we are going to complete our function by adding the required logic.
According to the requirement, we have to receive two numbers, complete the operation and return a result. It is that simple. Let’s create the code:
6. Finally, watch the test PASS!
At this point, just relax and execute the test command again:
$ npm test
Enjoy watching how the test passes!
Now that we have our function created with all the appropriate tests (this case, just one), we are done. If necessary, to create a new function (substrate for example) we will have to follow the entire cycle again. It is true that this process takes more time in our development cycle, but at the end of the process, TDD should ensure that most functionalities are working well.
I hope you enjoyed this series on Test Driven Development. Subscribe to our blog and stay tuned for more tutorials in the future. If you have questions, please leave a comment below and check out another example here in my personal github.
—
At Gorilla Logic we hire only the best software engineers. Think you have what it takes to be a Gorilla? Check out our careers section and follow us on facebook by clicking below!
