A small introduction 🔗When I first started blogging back in 2017 (damn it has already been 5 years…), I created a free blog on WordPress - https://danielsknowledgebase.wordpress.com. It was a really simple and nice way to get started with blogging. As time passed and I kept on writing posts, I noticed that I enjoyed it. For that reason, it seemed reasonable to invest in a custom domain, and in that way also enrich my online presence.

At my current job, we use a private instance of Gitlab to host the code, CI/CD, and such, and we also have private runners. I recently began working on a terraform script that became a module since multiple teams/projects can leverage such implementation. For this reason, it makes sense to have a repository dedicated to this module (or even more modules, but that can be another topic). The objective 🔗The idea is pretty simple: Have a git repository that hosts the module(s), and every other project that wants to use the them, reference the repository through the source = "git:: (...) terraform syntax.

In the previous post, we’ve created a simple pipeline that builds and tests our application. We know that our tests ran successfully, but that’s all. We don’t actually know how much code we are testing. What’s code coverage 🔗I really like the definition that was given in this stackoverflow post. As mentioned: Code coverage is a measurement of how many lines/blocks/arcs of your code are executed while the automated tests are running. Code coverage is collected by using a specialized tool to instrument the binaries to add tracing calls and run a full set of automated tests against the instrumented product. A good tool will give you not only the percentage of the code that is executed, but also will allow you to drill into the data and see exactly which lines of code were executed during a particular test.