ALL CODE IS GUILTY UNTIL PROVEN INNOCENT
In the world of Technology today, Test Driven Development is now a skill that is being demanded by companies, as a programmer today, testing skill is just as important as your development skill. In fact, it is a must-to-have skill now by most companies that will recruit any Software Engineer.
Working on a project Hello Books with my amazing teammates, we have chosen to use the TTD approach. For every Pull request that is raised by our engineering team, without tests to prove the innocence of the feature you are adding to the product, your PR will be rejected. This is because, without tests, no one can guarantee the quality and behavior of the feature the PR will be adding. To ensure there is a test for every feature, we set our default test coverage for the entire application to be 90%, which is just 5% above the initial coverage set by for us by Andela.
There are many testing frameworks and library out there today in the JavaScript stack. So for the Hello Books project, the instruction was to use the Mocha testing framework and Chai as an assertion library. Since Chai works perfectly fine with Mocha, both are a great fit for each other, we use the Chai-Http library built on Chai to test HTTP endpoints.
Mocha is the framework that provides functions that run the tests and outputs the results to the terminal window. Tests pass or fail based on assertions and chai is an assertion library. It provides functions and methods that allow the developer to compare the expected and actual outputs from running tests. By comparing these values, we can tell when a feature is behaving as expected and when it isn’t. One of the major advantages of Chai is the readability of its assertions.
Before any feature can be accepted by the tests are being run by Travis CI which is a continuous integration tool for running integrated tests on any application.
Below are some shared screenshots of tests written by me to test a feature on the Hello Books project.
Tests should always account for both passing and failing cases in other to get the proper test coverage and I believe tests should always account for both expected and unexpected scenarios so as to be on a safe side, cover all edge cases and ensure perfect application behavior.
Unit tests test function in isolation. But with integration tests, the developer can see how the function or method tested behaves in the context of the whole application or a major part of it. This is the best procedure I choose to follow so that other functionalities added to the application will not affect the behavior of the application.
This is the paradigm I and my awesome teammates follow to ensure the best possible product is delivered and I hope I have given you another reason to follow the TTD convention and make the world a better place for the users of the product. Cheers.
