It has been a little while since my last post. This post will be about my attempts at Unit Tests for my dedicated project—the project we are working on for God. If you are planning to use Unit Tests in your development, you may find some lessons after reading.

Yes, I say we are working for God because the project involves Digital Transformation for a large regional Church. To simplify for a quick understanding, the idea is to transition many of their manual workflows to be managed on the website and mobile app.

Before we delve into the details of the three unsuccessful attempts, let me briefly explain why we chose to build the app with Unit Tests. Many years ago, we set a mission to elevate the developers in our organization to a global standard, bringing them to the same level as modern developers worldwide, every developer to be a craftsman.

So my passion in this project lies in the complete process of coding, testing, and deploying. Our code should be covered by tests to reduce the effort of impacting code and fixing bugs. Every experienced person in software development knows that the time spent fixing issues is often more than the time spent building the software. Developers may claim they don’t have time to write tests, but they end up spending many hours fixing issues later.

At the beginning of the project five years ago, we understood the importance of Unit Tests for code quality. On the other hand, the project required a relatively short timeline to go live because they wanted to launch it before the Christmas event. So, we chose Drupal CMS for its scalability, a well-structured codebase, built-in support for JSON API, and a robust testing framework that includes support for Functional, JavaScript, and Kernel testing.

First attempt: We didn’t know how to test our code and we were rushing to meet the deadline.

The fact is, despite many years in software development, it is not an advantage for me to easily start with Unit Tests. I waste time learning and trying the test framework, understanding its methods, interpreting results, debugging the function code, and asserting. Typically, this is the time we spend when approaching a new technique.

I cannot identify the test cases for my code function. For example, if we need to write a function to add two numbers, what cases do we need to test?

• assertEquals(3, addNumbers(1, 2));
• assertEquals(4, addNumbers(2, 2));

or do I need some more cases?

• assertEquals(4, addNumbers(-1, 5));
• assertEquals(false, addNumbers(“a”, 2));
• assertEquals(false, addNumbers(3, “str”));
• assertEquals(false, addNumbers(“string”, “str”));

Many times, errors occur. After spending 3 hours debugging, I realize the function code is working correctly, but the error appears in the test code. So, I begin to wonder why I need to spend time on inefficient work.

Remember, Christmas is coming soon; we need to forget about the tests and focus on meeting the deadline.

Second attempt: The infrastructure is insufficient, we lack knowledge on running tests in large numbers and large database.

I noticed I am lacking in writing test skills, so I decided to learn from other senior developers. I spent nights joining the Drupal community and their chat room on Slack. I found some developers who have contributed significantly to the Drupal core and chatted with them at midnight, as we are in different time zones. They helped me understand the mindset of Unit Tests and provided examples for me to practice, starting from easy to more challenging functions. I also contributed tests for community modules.

Following a month of practice, I can now start writing tests for functions in the project. The complicated workflow seems easier with functional tests. Some workflows that require 30 minutes of manual input, clicks, and result checking can now be done more efficiently with Unit Tests, saving me time.

With a large of tests case has wrote, we decide to setup the CI/CD to the server, we want it should run automatic after the code has change. But at that time, the server could not complete all tests because it consumed too much RAM and CPU. Another issue is that our database is currently quite large.

After many unsuccessful attempts on the server and with some changes in team members, we temporarily stopped the Unit Tests. We are now focusing on implementing new features after completing the complicated workflows.

The third attempt: it’s just the beginning.

Many months have passed, and a lot of lines of code have been added. Now, the system seems messy, and issues may arise even from changing a small line. We initially think it won’t have an impact, but it does. We spend a lot of time debugging recurring issues.

After fixing an issue, some days later, we identify the fix’s impact, open a new issue, and fix the new problem. This loop happens too many times.

I decided to resume the use of Unit tests. Within a few weeks, I resolved all previous issues, including high RAM consumption and database problems. I also set it up on GitLab CI to execute for every code change. The remaining task is to support other developers in understanding and using it fluently. Despite a few challenges, as mentioned above, some developers find Unit Tests time-consuming. However, they end up spending a lot of time fixing code issues later.

After all efforts, our only goal is to become a craftsman in software development.