All About Unit Test
Deep Dive Into a Unit Test Area
I am pretty sure every software engineers have heard of unit tests. However, it is undeniable that making unit tests for some people is quite a headache, same as creating technical documentation: time-consuming, and other things. Even so, it is highly recommended to make a unit test because it has many benefits!
PREFACE
Okay! So, what is the unit test?
A unit test is the process of writing code to test the behaviour and functionality of the system. From this unit test, there is a typical pattern called AAA. Have you ever heard the word of AAA? It is the acronym of Arrange, Act and Assert. AAA is a way to structure your unit tests, so they are easier to read, maintain, and enhance.
Hmm… Is there any benefits if we implement the unit test? The answer is: “Yes, it is! Check it out!”
- It makes you more easier to change the technical implementation while making sure there is no broken behaviour, for example, when doing refactoring.
- It gives the developers more confidence when adding behaviour or making fixes.
- It makes the debugging process more easier.
- It provides technical documentation for other engineers.
Okay, well noted 🗒! Is there anything I need to know before jump in to the implementation? Yes, it is! Let’s dive in more to see more about the explanation below
To make it clear about the unit test, we can follow the Pyramid of Testing concept. And as a note, you have to understand about what you have to test. You can consider a normal function (every requirement is fulfilled. e.g.: complete parameters), a function without parameters (should be giving error, except parameter-less feature), and also several edges cases.
Key to Success
When you have to write a unit test, it should be considered as GOOD. What Makes a Good Unit Test?
- Easy to write. Developers typically write lots of unit tests to cover different cases and aspects of the application’s behavior, so it should be easy to code all of those test routines without enormous effort.
- Readable. The intent of a unit test should be clear.
- Reliable. Unit tests should fail if there’s a bug in the system under test.
- Fast. Developers write unit tests so they can repeatedly run them and check that no bugs have been introduced.
- Truly unit, not integration. Should not access the network resources, databases, file system, etc., to eliminate the influence of external factors.
So, what I am going to do for implementing it?
Don’t worry, Haha! I will show you how to do it after this section 😉
MODULES
Now, Let’s talk about what kind of tools which will be used for creating a unit test. In this case, I am using Node.js as the primary language. There are four tools I usually use when starting to develop a unit test:
- Test runner: mocha
- Assertion library: chai (for asserting)
- Test spies, stubs and mocks: sinon (for test setup)
- Code coverage report: instanbul
For your information, when you jump into this unit test, there are some vocabularies you should remember in your mind, such as:
- Spies: The main purpose is to get information on function calls, like how many times they were called, or what arguments were passed to them.
- Stubs & Mocks: Those two are quite similar, but there is a difference between them. According to this article, Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’. Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
- Code Coverage: To get a better idea of how well your codebase is covered with tests. This report will include metrics on line coverage, statement coverage, branch coverage, and function coverage.
Please keep in mind, when you create a unit test, mocking too much will reduces test quality. Then, if you want to use real data or mocking is okay, but you shouldn’t use both in a single test. Last but not least, each test case must not depend on each other.
CODE SESSION
Let’s jump into the code session. In this part, I will guide you through creating a unit test. Here are some guidelines you can follow when writing a unit test:
- describe() is merely for grouping, which you can nest as deep
- it() is a test case
- before(), beforeEach(), after(), afterEach() are hooks to run
For a better understanding, let’s do the implementation step by step on the controller, for example :
- Inspecting the code:
- Setup the mocked modules:
- Prepare all test setup requirement, then define the main test scenario and it’s children with using describe and it. But, you have to remember that nested describe is allowed to use and nested it cannot be undone. See the guidance below:
So, that’s it. Thanks for reading, I hope this gives you an idea of what is a unit test and how to create a simple unit test with Node.js.
References and Further Resources:
