Unit Testing Clarified, Part 2: FAQ

Continue from Part 1.

Q & A

1. Why do the tech leads/managers/programmers use the ‘Unit Test’ term wrongly?

Managers are excusable, but not for ‘tech leads’ and programmers. The short answer is that these tech leads have never written nor executed real unit tests. This is very concerning. We know that “Good programmers write unit tests”, and the T in TDD (Test-Driven-Development) is Unit Testing. If we have these fake/incompetent engineers as the tech leads, the project will be doomed.

Let me share an interesting story. I worked as a contract programmer (C#) on a large government project many years ago. I started writing unit tests (a practice I took from years of coding in Java) using NUnit. Soon, I used NMock for mocking in unit tests. One day, the tech lead came to my desk and told me to “Delete the unit tests!”. Yes, you heard it right. His reason was, “You are using technology (NMock) that our future support programmers are unable to maintain”.

I was shocked. I emailed him with a quote from MSDN: “NMock can greatly enhance the design” and asked him alternate ways for mocking in unit tests. The reply was simple: “Delete the unit tests. Here is check-in task ID.” (at that time, every check-in required a task to be associated with). I wished I took a screenshot of that email, but I did show it to some people. They thought it was crazy too.

Clearly, this was a human issue, but it is fundamentally about the team programmers who do not understand unit testing and have never done it properly. Now that Test Automation, CI/CD/CT and DevOps are hot topics in IT, these incompetent engineers want to get involved ….

2. Do you do unit tests?

I retired from programming as a daytime job in 2011. I switched to work on Test Automation and CT during the day (for others) and develop my own software in my spare time (for myself). Before that, I followed TDD (writing unit tests first) since I mastered effective unit testing in 2006 (learned from a master) and asked my team members to do it as well.

However, as I was getting more efficient with automated E2E testing (using TestWise: next-gen functional testing IDE and BuildWise CT Server/Agents, disclaimer: I created these tools), my focus switched to “Daily release to production”. I implemented most (>95%) of the customer requirements the next day (I will write an article on this soon).

This means I need to spend my time wisely. I focused my most testing effort on automated E2E (functional) testing. Still, I would write unit tests first for a feature with complex logic, such as workflow.

3. How do you learn to write better unit tests?

Many skills in software engineering, such as automated testing (unit/functional/load) and CI/CD/CT, are rarely taught at university. As you have probably found out already, very few did well despite almost all software projects claimed to have been conducting these practices.

My solution: find a real professional (colleague/consultant/coach), pair-program with him/her.

4. I found writing some unit tests simple but hard for other functions.

This mostly means that your software design is not optimal. Writing unit tests is not simply verifying a function. More importantly, in my opinion, it is to verify your software design. Generally speaking, it is easier to write unit tests for well-designed code. For example, back in my Java days, writing unit tests for the Spring framework was a lot easier than EJB.

Why should software professionals do automated testing (unit and functional)?

Many developers write automated unit tests unwillingly. Because “Good programmers write unit tests” is well accepted in the software industry, programmers who do not have the skills often try to write some unit tests and soon give up. Besides technical aspects, I think software engineers and IT managers should first upgrade their understanding of test automation's value.

In my opinion, the reasons for doing automated testing (unit & functional) are:

• to provide benefits to the customer. Customers like frequent and high-quality releases. With a happy customer that trusts the team’s capability, everything is a lot easier.
• to provide quick feedback to the team. If we can find out regression issues earlier, it will be much easier and cheaper to fix. The feedback from unit tests is quicker than E2E functional tests. Given automated E2E regression testing is in place, effective unit testing is always welcome as it provides much quicker feedback. To achieve it, you need a capable team to be able to design and maintain a good unit test suite.

With a green build (passing all automated unit and E2E functional tests) every day, programmers can go home with pride. This is priceless.

--

This article was originally published on my Medium blog on 2021-08-22.