You are reading this blog for two reasons. First, you are a tester / developer. Second, you want to be a better tester / developer. We need better testers and developers in our small little world

If you have been a developer for couple of years, you have probably been significantly slowed down by someone else’s messy code. If you have been a developer for longer than two or three years, you have probably been slowed down by messy code. The degree of the slowdown can be significant. Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they can not clean it up. There is no way at all.

Better Test would have aided to prevent the above stated problem to some extent , but cannot prevent it completely

CONCEPT of FIRST

Clean tests follow five other rules that form the above acronym:

Fast Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently. If you don’t run them frequently, you won’t find problems early enough to fix them easily. You won’t feel as free to clean up the code. Eventually the code will begin to rot. For these reasons, your test should be automated

Independent Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like. When tests depend on each other, then the first one to fail causes a cascade of downstream failures, making diagnosis difficult and hiding downstream defects.

Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network. If your tests aren’t repeatable in any environment, then you’ll always have an excuse for why they fail. You’ll also find yourself unable to run the tests when the environment isn’t available. E.g. Have the same tests run across different browsers on different machines

Self-Validating The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass. You should not have to manually compare two different text files to see whether the tests pass. If the tests aren’t self-validating, then failure can become subjective and running the tests can require a long
manual evaluation.

Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.

Conclusion

It’s not enough to write the tests well. The tests has to be kept clean over time. We’ve all seen test rot and degrade as time passes. So we must take an active role in preventing this degradation.

It is always important to remember, that job of a tester is always to prove that the programs / SW is not working, but the current thought process of our testers is not in the same line.

The concept of 5 developers to 1 tester is never understood by me (may be I am less educated), it is important to note that testers require to think from multiple angles , that of the business or from the developers view, of how the code would have been written.

The concept of 5:1 ratio is a gross mis-match in our industry, It is important to note that testing can only confirm the presence of bugs and the absence of it.

We have barely scratched the surface of this topic. Indeed, I think an entire book could be written about clean tests. Tests are as important to the health of a project as the production code is. Perhaps they are even more important, because tests preserve and enhance the flexibility, maintainability, and reusability of the production code. So keep your tests constantly clean. Work to make them expressive and succinct. Invent testing APIs that act as domain-specific language that helps you write the tests. If you let the tests rot, then your code will rot too.

Keep your tests clean.