Day 21 | #100DaysOfCode
Tests are your silver bullet for Clean Production Code
TDD is cool, but know how to do write the Tests cases professionally
We code some module, then we write some ad hoc lines of code just to see if our module is working the way it is expected, then we throw away those lines of code. Now there are Agile and TDD movements that have encouraged many programmers to write automated unit tests, and its popularity is growing day by day.
But in the mad rush to add testing to our discipline, many programmers have missed some of the more subtle, and important, points of writing good tests.
3 Laws of Test Driven Development
We all know TDD asks us to write Unit Tests First before we write the production code first! But that’s just one high-level rule.
Rule 1 — You may not write production code until you have written atleast one failing unit test. Don’t start too positive 😉
Rule 2 — You may not write more of a unit test than is sufficient to fail. Dont’t write multiple failing logic into one test case. Remember it’s called a Unit Test case.
Rule 3 — You may not write more production code which is sufficient to pass the currently failing test. Only write enough code to pass the unit test.
Learning the hard way
Once, there was a team of developers, they had a rule of maintaining high-quality production code but they had licensed each other to write Quick and Dirty test cases. The test functions were not properly named and structured.
The variable names weren’t descriptive, functions weren’t separated logically as long as they passed the requirement of checking their production code, they were absolutely fine with it!
But Having quick and dirty test functions are better than having no test functions at all. Something is always better than nothing. Right?
Wrong! having Dirty Test is equivalent to, if not worse than, having no tests at all.
As professional developers, our responsibility is to update the Tests as our production code is updated. The dirtier the tests are, the harder they will be to update and they will also take longer to update the tests.
Once you change the production code, the tests need to be changed as well and since there is a mess, it will take more effort from you to do that. See how the tests are becoming an ever-increasing liability?
Back to the story, From release to release, the cost of maintaining the test suites increased, the manager asked why the estimates are getting large, they blamed the tests and then the entire test suite was discarded. Now they had no way to ensure the production code worked perfectly.
The defect rate began to rose and with time the number of unidentified defects rose, they start to fear to make changes. They stopped cleaning the production code as they feared changes might do more harm than good. Production code began to rot, no test cases, frustrated customers and they were thinking that the test cases failed them.
Moral of the story — Test code is just as important as production code.
If you don’t keep your tests clean, you lose them. It is the unit test that keeps your code flexible, maintainable, and reusable. The reason is simple! If you have tests, you don’t fear to make changes! Hence, having an automated suite of unit tests that cover the production code is the key to keeping your design and architecture as clean as possible.
Your tests should be as Readable as possible. Readability in tests is far more important than in the production code. Readability comes from Clarity, Simplicity, and Density of expression. Apply the same principles which you have learned above for the Tests as well.
To help you write Clean Test Code here are...
5 Rules for Clean Tests — Remember FIRST
Fast — Test should be fast, should run quickly. Only then you won’t hesitate to test your production code frequently.
Independent — All your test cases should work independently of any other test case what so ever.
Repeatable — You test should behave the same / repeat itself in different environments. Environments shouldn’t be a deciding factor for the tests. Either be it on your laptop or QA’s laptop test should run the same.
Self Validating — Test should have a boolean output. Either they will pass or fail! There shouldn’t be any manual work of comparing the outputs in the log file. As including some manual evaluation will only extend the time of the test and hence clashing with the first rule.
Timely — Test should be written in a timely fashion. A unit test should be written just before the production code that makes them pass. If you write production code first, you might find some parts of code untestable, hence you should always write test function first.
Remember, If you let your tests rot, your code will rot too!
Interested to learn more about Clean Code? Make sure to check out the previously written articles on Clean Code.
That’s Day 21st of #100DaysOfCode
Remember, if you want to make this learning worth it:
- Go ahead and apply your knowledge and make some good out of it!
- Teach this to someone and get to learn this again!
- Share this post with a friend whom you think should learn more about Clean Code
Thanks for reading, and as always you are awesome ❤
