Project Update - 2

This is a continuation to previous post on our new side project. Instead of building a spaghetti code that just works, we are approaching the entire process through the industry practise.

For example, the working components are modularised for easier maintenance. These individual modules are built on TDD approach, testing with every step of our development. The test results are passed through coverage to understand how much code is covered under our testing process. And, based on this coverage status the code is committed into Git repo. This regulates clean and working code.

Modularisation

All of our code is built into classes. Each of the class consists several methods to carryout particular task. While development, its much easier to test individual methods than an entire file.

Test Driven Development

During day my work revolves around databases & data pipelines. It took me a long hours to understand the workings of TDD. The concept is following one of the mental model called Inversion.

Inversion involves looking at a problem or decision from the opposite point of view so, for example, rather than focusing on achieving success, Inversion encourages you to consider how to avoid failure. - ModelThinkers.com

In TDD, we build test case before the actual method. So we start with failed case, gradually proceed to our expectation. Once the test-case passes, we add more cases to catch edge cases if any. Finally, once the test cases are returning TRUE to all the cases (that we handled), we can commit and move on to next method.

Currently, I’m not entirely comfortable with the TDD process. Instead, I create test methods after the successful run of method. I am aware this is spoiling the joy of TDD, for now adhering to TDD process is one of the to-do item that resides happily in the backlog bucket.

Code Coverage

Code coverage is something that I never used or seen at my work place. But this is highly prevalent in Open source communities. The percentage of code covered by our test cases shown through the readme badges pulled me into using them.

Pre-Commit

Another tool which I never used at my work. Pre-commit is a net to fish out bad/substandard code from entering into our repo. As per the name, the preset rules are applied on our files, if there are any deviation from the standard the pre-commit throws an error, or some cases it fixes the minor hiccups - like limiting one package per import, et al.

CI

Continuous Integration sits on top of everything that’s mentioned above. With every code commit into repo, the CI gets called automatically and performs unit testing. If all the unit test case passes and coverage score is above the threshold, the CI shows as success. The result gets in the middle of merging branch with the main.

Documentation

We are using docstrings to capture the functioanlity of each of the methods. Currently, the docstrings are added to methods that are passing test cases and committed to the repo. But ideally, they must be added during the development phase. This needs to be taken care during the upcoming iterations.