Pessimistic Programming — Test

Tung Nguyen
4 min readOct 29, 2020

On the early days of my coding life, I implemented a small feature in a given ticket with totally wrong code which will be in my mind forever for sure. Particularly, the code completely contrasted with the business logic of the feature. But somehow the ticket passed both my test and QA test to go through to staging in a release along with some other tickets. Technically, the wrong code can be illustrated as below:

if (!anObject.isRightSide) {
//Do something
}

In expectation, it should be implemented as:

if (anObject.isRightSide) {
//Do something
}

Honestly, this is just one real story in many mistakes which I made or knew as a developer up to now. A mistake is just a mistake and it always exists around us. The fault looks stupid but it proves that a mistake can appear anytime, anywhere in programming, called a bug. So that, personally I think a developer should be a bit “pessimistic” because we are not sure that a program is perfect and it does not have any bug. We have to accept that our code may have bugs and we must prepare ways to deal with them. Simply, it is “Pessimistic Programming”.

Obviously, all we know that a small bug may cost a lot of time as well as effort to investigate and fix. Furthermore, it may affect to progress of a software development circle or even more. Hence it is better to kill any bug as soon as possible in coding time. Up to now, how could such unbelievable mistake happen and pass QA checking still be a question. I still do not know why I added “!” in the condition statement but I do know that a proper unit test can help me to detect and correct it at the early time.

As I know, unit test is not mandatory in many software companies. They may have their own reasons to skip unit test in software development. But from my point of view, unit test should be required for developers and we should define a certain volume of test coverage to strictly follow. I quite disagree if someone says that ignoring unit test helps to speed up development. Skipping unit test may help the coding phase faster but let’s imagine how about the next phases. You may lose your time in QA, bug fixing and maintenance later.

What should we do with unit test?

Detail of unit test such definition, boundary, tips can be reached in Martin Fowler’s articles in references section. Here I state what should we test in some sentences:

- Model: Test complicated calculations, behaviors, state transitions in modules as black boxes through their interface.

- Repository, gateway: Verify logics used to produce requests or map responses from external dependencies rather than to verify communication in an integrated way. Uses doubles to simulate request and response cycle.

- Service, resource layer: Test coordination between modules through double messages and stub responses.

Unit test has its cost. Keep it small, focused and high value.

What are the benefits of unit test?

Unit test leads to less bugs in your program

- The more coverage your code has, the less bug your program has. If I write a test case for the code above, the bug will never happen for sure.

- Your program grows day by day. How confident you are if you made a small change in your code for a certain use case and your code passes all the other cases.

- How confident you are when you release a feature with 100% your code covered by unit test.

Unit test leads to more quality program

- Unit test helps your code loosely coupled: Practically, if you want to test entirely your class, you need to make your class independent with its dependencies by controlling output of the dependencies with doubles. In consequence, you need to apply Dependency Injection pattern.

- If a piece of coordination logic requires too many doubles, it is usually a good indicator that some concepts should be extracted and tested in isolation. Specifically, if cohesion of a class is not high, you will get complexity in unit test. Then you need to split your class into small parts in order to make your code cohesive.

- Imagine that you decide to refactor your code, how easy for you if you already has enough unit test for the code? Just refactor anything you want and run unit test again. If all the test cases pass, well done.

Conclusion

In conclusion, test coverage should be a factor to evaluate quality of a program. We should take unit test into consideration as an important and mandatory part of software development. As a developer I always try to write unit test for my code, by that I can make sure that my code works smoothly before pushing it to other steps. If you are interested in unit test, TDD is a fascinating topic for you.

References

[1] https://martinfowler.com/bliki/UnitTest.html

[2] https://martinfowler.com/articles/microservice-testing/

--

--

Tung Nguyen

A coding lover. Mouse and keyboard are my friends all day long. Computer is a part of my life and coding is my cup of tea.