Writing Tests for our code is as essential as we bring new features in our CLI. Unit and Integration Testing helps us in automating the E2E testing, which makes things easier for each developer and brings certainty for a new developer that his/her code changes aren’t breaking any previous features, functions or a mesheryctl command.
We use CodeCov to calculate the code-coverage in mesheryctl. Search for Issues marked with area/tests in GitHub - meshery/meshery: Meshery, the service mesh management plane.
- Codecov is used to check code-coverage in mesheryctl (login with GitHub to get an in-depth idea of lines-of-code being covered in code coverage).
- You can check the files in CodeCov’s website to figure out which files/functions/lines-of-code haven’t been covered by existing tests.
- Guide: Writing tests for mesheryctl. This guide will help you give a brief intro about how tests are supposed to be written for mesheryctl.
- Contributing to Tests doesn’t always means writing new tests, It also means improving the effectiveness of already written-ones.
Unit Tests can be written in two ways-
- Test mesheryctl subcommand
1.1 Mock Meshery(backend) response if needed
1.2 Grab console output
1.3 Store standard/verified mesheryctl output in a golden file(a text file)
1.4 Match the stored/expected output with what we grab from the console
1.5 Cover as many scenarios as possible, test the situations where errors must be thrown
1.6 This is a standard format, changes can be made accordingly - Test mesheryctl functions
2.1 This is the standard testing you may have came across every project
2.2 You write one test dedicated to one function covering all possible test-cases, matching expected outputs
Integration Tests-
- Integrations tests come in frame when we can-not mock things and when we need to make sure action does complete when all the necessary requirements are fulfilled.
- For e.g.
mesheryctl system start. The command is in-fact supposed to start Meshery. - So we run the command to start Meshery in GH workflow and after running the subcommand through the Tests we make sure that Meshery actually started. And if we successfully checked it, boom we aced writing Integration Tests.
- Writing Integration Tests is however a tough task to tackle, but yeah that’s the fun part, running and making sure a command that’s hard to test, and making it automatic through GH workflows.
One most important note-
Writing Tests and making them work is in itself a tough task to do, so even writing one test for a single function counts and makes a big difference over the period, so do not hesitate, start writing tests.
Writing One test is enough to raise a PR and to get yourself started with Testing.
The impact that you make with these tests is very high, I can’t even explain in words (I don’t have that good of a vocabulary). Your Tests are going to run in each PR raised for Meshery, for each commit someone is pushing to the PR, so if someone is damaging the supposed behavior of code, your tests is going to catch them red-handed, how cool is that? 
And yeah if you’re reading this, make sure to raise a PR with Tests for mesheryctl and add me to review those! Let’s get mesheryctl that 100% code-coverage badge
