Check out part 1 here: From adopting spaghetti code to 100% test coverage
A Paradigm Shift
As the GitLab CI pipeline gets set up, merging code becomes such a drag. It takes minutes to run unit tests, and unit test coverage is lower than 10%. Getting to 80% might feel like a nightmare.
As such, here is a revisit on unit tests, this time favoring Shallow tests over Mount tests.
Talked to a colleague over tea break today, and he said that at his previous company, it was near 100% tests, and the CI pipeline took 15 minutes to run unit tests. It was such a far cry from what we have here, so I had to revisit my unit testing philosophy of: MOUNT ONLY.
Shallow tests
While you want tests there to ensure that code changes do not break existing functionality, you also want to reduce time spent waiting for CI pipelines to run.
What I forgot previously was that unit test was just the first of many tests:
By doing full mounts, all the nested function calls end up running / rendering, which takes time.
The problem with shallow testing is that it is very limited and cannot test much functionality.
The solution
We need to build this on SOLID foundations (.. I mean S.O.L.I.D principles -lol-). Single responsibility principle is a good idea to keep in mind here.
The idea is to keep unit tests having single responsibility. If a function that renders contains another function:
- Write a unit test to test the render function render correctly, mocking the function return value, and
- Write a unit test to test the other function.
There will be more tests to write, but it should reduce wait time for unit testing in the CI pipeline! (Let me get back to this in... 1 month or so?)
Top comments (0)