Tests ft. Clean Code

Clean Code….Naam to suna hi hoga (Famous SRK dialogue). A book which is followed by many engineers to write perfect code. Today we will cover Chapter 8 : Unit Tests. The purpose of this post is to make a summary of the chapter so that you can revisit it quickly. I strongly recommend to read the chapter entirely, this is just for revision purposes. So let’s begin.

Need for clean Tests:

1. Tests are a crucial part of software engineering. In the recent time TDD and Agile movements have made developers write more tests.
2. With this pace, developers end up writing tons of tests.
3. In many cases teams end up writing Tests with poor quality as compared to the production code.
4. As a result over the period of time tests become too large and they are very difficult to change and maintain.
5. Not writing tests is one solution but it wont give developers the confidence to add new features or refactor the code.

Advantages of Tests:

1. Iteration is easy as everything you change is run against the test and you can see the impact of the changes throughout the code base.
2. Fear of adding changes is reduced.

Clean Test:

1. Readability makes tests clean. Its code quality should be at par with the production level code.
2. BUILD-OPERATE-CHECK pattern is very handy, you first prepare the data for the test, then trigger the methods to test, then verify them against the result.
3. Tests should not contain code which is not relevant to the test scenario. For ex. while preparing the data, you should not have long logic to prepare data in that test.

Dual Standard:

1. The test code should have the same quality as that of production.
2. But the test code should not necessarily be as efficient as the production code as it runs in the test environment. For example not using a String Buffer in a test might not be the bad choice if it makes the code more readable.

One Assert Per Test:

1. As the heading suggests one test should have one assert.
2. Having more than one assert means that we can split the tests into multiple tests.
3. We can use @Before in java to put all the common code when we split the tests, or we can put them in base class and then extend the test class from it. Obviously it depends on the amount of duplicity you are dealing with.

Single Concept Per Test:

1. A test should test only one scenario.
2. Multiple tests should indicate multiple scenarios.
3. This gives a clarity about which all scenarios are tested and it’s easy to maintain.

F.I.R.S.T:

1. Fast: Test should be fast, so that developers should run them often and catch the failed test early.
2. Independent: Test should not depend on each other as the failure of one should not lead to failure of another.
3. Repeatable: Test should be repeatable(able to run) on prod, local, pre-prod. The reason for failing the test should not be the environment in which it’s running.
4. Self-Validating: Test should tell whether it passed or failed which means output of the test should be binary so that we don’t need to go and do some comparison to see if it is passed or failed.
5. Timely: Tests should be written just before the production code, so that we will end up writing the prod code in a testable manner. Otherwise we might end up writing the prod code which we can test.

Hope you enjoyed it and I was able to put the summary in the most readable format.

If you have any feedback, please feel free to comment or reply to the email.

If you like this and want to read more, please share this and subscribe Newsletter .

Find me @darshan_kadu

Cheers 🍻. See you again.