A Tester's Letter to The Developer

Hi Mr. Developer,

I hope you are doing fine.

You may know me very well. I am Mr. Tester.

I know you don't like me much and I can understand that. You create something and I normally point out defects in your creation. It is natural to not feel good about that.

I am not here to convince you to like me. I am not discussing either about Tester vs. Developer debate here. It has been discussed time and again and I know you get that point and you now treat me as a fellow and partner and not an enemy. And.... thank you for that. I treat you as my partner as well.

I am writing this letter for something else.

I know you are very knowledgeable and what I am about to tell you, you probably heard it many times as well. So I probably will not increase your knowledge.

There are 2 types of testing. 

White-box testing and Black-box testing. (I know you know that)

When I was a fresh graduate, I was told Black Box testing was done by Testers and White Box was done by ....ahem ahem ...Developers.

Let me rephrase testing types again for you.

There are two types of testing. 

Testing from the code side and Testing from the user side.

We, as testers take care of the user side of the testing. There are many stakeholders in the project and each one, to some extent, tests the application from the user side. No other stakeholder will test from the code side except for one which is you. The Developer. Everybody assumes (and rightly assumes) that unit testing will be done by you.

Not every developer ignores Testing from the Code Side.

I found out that this testing is routinely done by other developers in big organizations like Google, Microsoft and Facebook.  

You can object that these are big organizations and their developers can do it. But even developers who develop open source software, they are doing it.

I was reading a tutorial on Django Framework and that paragraph got my attention:

“You might have created a brilliant piece of software, but you will find that many other developers will simply refuse to look at it because it lacks tests; without tests, they won’t trust it.”

Jacob Kaplan-Moss, one of Django’s original developers, says “Code without tests is broken by design."

So then why you are not doing it?

Maybe you are unaware of the benefits. (I am making good assumptions about you)

So let me state some benefits of Unit Testing for you.

Tests will save you time.

Your first objection on not doing unit testing can be the lack of time. You have so many features to develop, tasks to do and bugs to fix. Adding another weight of writing unit tests may seem time-consuming. But, in reality, Tests will save you time.

You develop sophisticated applications. (Yeah) You might have dozens of complex interactions between components. A change in any of those components could have unexpected consequences (read bugs) on the application's behavior. If a problem occurs, you will spend hours manually trying to identify the cause. 

If you have written unit tests, these tests could execute in seconds and quickly point out which piece of code is the real culprit. (Before release)

Sometimes it may seem boring to tear yourself away from your productive and creative programming work to face the unglamorous and unexciting business of writing tests, particularly when you know your code is working properly. But once you accept its benefit, it will save you a whole lot of time in debugging. (And also, a lot of time of testers who have to test the defected build and then find the bug for you which could have been identified in unit tests.)

Tests will just not identify the problem, they will prevent them.

The presence of unit tests makes sure that any new change does not bring any regression to existing code. If any test case fails, you can know before release that where the actual problem lies. Bugs which are found earlier in the process are lot easier to fix. Also, it gives confidence that major functionalities are still working after new changes. When you develop a feature and write unit tests for it, you will feel a lot more confidence about this feature because you know that this feature will not break in the future due to other code changes.

Tests will make your code more maintainable.

When you begin to write tests, you will feel that much of your code is not testable at a unit level. This will force to break the existing functions into smaller functions which are more modular and generalized in nature. This automatically makes your code more maintainable. 

Tests help teams code together seamlessly.

The previous points are written from the point of view of a single developer maintaining an application. Complex applications will be maintained by teams. Tests guarantee that colleagues don’t inadvertently break your code (and that you don’t break theirs without knowing). 

By now you must have been convinced that you should write unit tests. But I will not stop there. I would like you to show some strategies to start doing unit testing right now. After all, I am your friend Right?

Strategies: 

1. Sometimes it’s difficult to figure out where to get started with writing tests. If you have already written several thousand lines of code, choosing something to test might not be easy. In such a case, it’s fruitful to write your first test the next time you make a change, either when you add a new feature or fix a bug.

2. Some programmers follow a discipline called “test-driven development”; they actually write their tests before they write their code. But if you are not comfortable with that, you can code first and then write tests for it later.

3. It might seem that your tests will grow out of control. At this rate there will soon be more code in your tests than in your application.

It doesn’t matter.

Let them grow. For the most part, you can write a test once and then forget about it. It will continue performing its useful function as you continue to develop your program. At worst, as you continue developing, you might find that you have some tests that are now redundant. Even that’s not a problem; in testing redundancy is a good thing.

4. As long as your tests are sensibly arranged, they won’t become unmanageable. Good rules-of-thumb include having:

• A separate TestClass for each module.
• A separate test method for each set of conditions you want to test
• Test method names that describe their function

5. Sometimes tests will need to be updated. In that case, many of our existing tests will fail - telling us exactly which tests need to be corrected to bring them up to date, so to that extent, tests help look after themselves.

Mr. Developer, I respect your work. The above is a friendly suggestion. This suggestion will not only benefit your organization but will also make you a better developer. After all, quality is not just a list of features, it is an attitude. 

I hope you will not take this letter as an offense on your development practice. Take it as a brotherly suggestion, given out in the love of quality.

Thanks for reading this letter.

Feel free to write me a reply (and telling me that you have started writing unit tests)

With Love and respect,

From your friend and partner, 

Mr. Tester. 

Credit: This letter would not be possible if I hadn't read the excellent tutorial on Django Website about unit testing. Full credit to their documentation team 

https://docs.djangoproject.com/en/1.9/intro/tutorial05/

Note:

If this letter can convince only 1 developer to start unit testing, I think the purpose will be fulfilled.