Hi Demand Platform, Features, Scraping, Pricing, and Affiliate folks!

Did you know that we can track the unit test coverage of our repo through this link? https://jacoco-report.test.tvlk.cloud/backend-monorepo

If you go there, you can see that our project (hotel) is just below the 20% coverage mark. You know what? This is a 5% increase! ...since last year

:smile:

This is not really an ideal pace. I'm curious as to what the blockers are that preventing you from writing tests. I'm wondering if I should have another sharing session on doing unit tests, but the gist of why you should start writing tests (if you haven't already) are:

It gives you assurance that the code you just write works.
It gives you assurance that when you change and refactor your code (tomorrow or the year after), the code will still work (preventing regressions).
It gives other people assurance that when they change your code, the code will still work!

Basically, what would you do if, on your code review, I randomly asked, "how do I know this code works as intended?" The ideal answer from you would be: "I wrote some tests for it, they cover the happy path and corner cases, and they all passed."

Did you know? High test coverage (and good test suite) will allow us to adopt Continuous Deployment (CD) pretty confidently! If you dream of getting your code live into production as soon as you land your changes to the release branch, it will always be a dream if we don't improve our tests.

Sadly, improving the tests of our evergrowing codebase can't be done just by a single or a few select people. It needs to be done by all engineers introducing changes, and should become a habit.

So, what can we do now to improve things?

If you work on a service impl or util class that don't have test class, create one. It should at least be as short as defining mocked dependencies and constructing the service impl class. Constructor-test-only test classes are better than no test classes at all!
If the class you're working on already have a test class, add at least one test case that tests your change.

Of course, the two points above are the bare minimum requirements for us, to improve our test coverage in small steps. Ideally, we should be thorough in writing our tests so that the goal of having confidence in our code can be achieved.

Remember, skipping tests will save you time now, but will cost you time later (debugging silly logic errors, etc.). Invest time upfront to save you time in the future.

Feel free to ask me and ping me on slack/IRL about anything related to testing and writing unit tests.

Keep calm and write tests!

Let's write tests!