This week had been another new learning experience. I learned about automated testing, different testing framework, various test cases, code coverage analysis and continuous integration. To apply my very amateur knowledge about writing test, I started coding in my CL tool, find-broken-link(fbl).
Testing framework/tools
The testing framework I chose is Jest. It is a popular Javascript testing framework and as my project is in node.js, I felt this framework is perfect for me. Another reason I chose this framework is because of abundance of example available online.
Set Up The Framework
To set up Jest in my project , I took following steps:
- install jest:
npm install --save-dev jest - install eslint-plugin-jest:
npm add --dev eslint eslint-plugin-jest - configure in .eslintrc.js:
jest/globals:true - add it to script so that I can run jest from command line:
"scripts":{"test":"jest"}
Learning Process
The goal was learning as it was my very first time writting test. I learned how many test scenarios you can have even for one line function . I only wrote some unit tests for my projects. One is for version.js file and other is covering two functions in util.js file. Some test cases I covered were:
- check if return value is correct
- check if return type is correct
- check if right parameter is passed
- check if url is good, bad, redirect, unknown with nock
- check if output is printed in right format and right colour
- check the right output based on config file’s different parameter
Mock network dependent tasks
For network mock tests, I used nock. It is easy to use and there is detailed example avialable in their documentation for that sort of sceanrios.
Uncover any interesting bugs or edge cases
While writing tests, I found that my functions are not very modular to write test for. For example, most of my functions do not return any value. As a result, I could not access the changed value and write a test for it. Because of this reason, I changed storeJsonData functin to return Json object instead of storing and printing at the same time. Also, by doing so, I was able to declare the json object as local variable instead of global variable. Using global variable was another inefficient part I identified.
Another problem I found was instead of throwing error, I used console.log. As a result, to test for error, I had to write whole bunch of code to set up console log which is unnecessary where writing tests to check throwing error only requires ONE LINE!
Adding code coverage analysis
Adding code coverage analysis was way easier than I imagined. Only change I had to do add "coverage":"jest --collectCoverage"inside script of pacakage.json file. Then, I ran npm run coverage which presented report for the tests I wrote. I covered 100% in one file, but the other one has a lot tests case to cover as it consists of various functions.
Set Up GitHub Actions CI Workflow
To set up GitHub Actions CI Workflow, I used “Actions” in GitHub and chose node.js CI. It was straight forward. After choosing the action, it auto- generated node.js.yml file inside .github/workflows folder. Now, all the tests will be run upon any PR or merge time rather than manually typing npm run test
All the instructions of writing tests and setting up can be found in CONTRIBUTING.md file .
Write Tests on Other’s Repo
Finding partner was a little bit struggle. Either whoever I asked already had a partner or they did not start yet. Later, I found one of my classmate who also did testing in node.js. I contributed on https://github.com/lixiaoqity/testLink repo. I found the repo is organized and easy to understand. I added 2 new test cases. Here is the PR: https://github.com/lixiaoqity/testLink and later it got merged!
In conclusion, the experience was great. I enjoyed writing test so far. There is many more tests needed for my CLI tools. Whenever I will find time, I will add more. The biggest lesson I think is that tests not only check for the right output, but also your code efficiency.
