We always see the supporters of the test-driven development always muttering their three words mantra “Red, Green, Refactor”. This is a simplification of the TDD cycle that requires you to demonstrate test failures before writing the code to make it pass.
The interesting part of the mantra is extracted from the tools incorporated. A spotlight color scheme is used to point out whether a test is failing or passing. Red shows that you run test via a unit testing tool and expectations by the test are not entirely met. Green shows that your test meets the expectations and no errors occurred during the execution.
A test demonstrates a new behavior via code that works with the fundamental system, in TDD. The test declares that predictable conditions hold true at the end of that interaction.
It may not compile when first written, because the test is describing yet-to-be implemented behavior. The developer might take some time and attempts to develop enough code prior to the test being executed in the unit testing framework. These additional steps are failures, nevertheless, they are not the red we want to see: A test should completely describe the new behavior prior to considering the red part of the TDD cycle.
Keeping this scenario in mind, I am listing down three useful things that Quality Assurance testers must learn from failing tests or seeing red.
1. Paying Attention to The Feedback
Test Driven Development is a very simple feedback system. The color at every step indicates whether you are ready to go to the next step. A red or failing test is feedback that demonstrates your test signifies an appropriate description of the new behavior. The description encompasses a minimum one declaration whether the proper result has been attained. A passing or green test is feedback that your system followed all the commands it has been asked to follow. You can select to clean up its application via refactoring, to write an extra failing test to add more behavior or to deliver what you have.
Also Read: Software Testing – As A Layered Cake Approach
2. You Go Back and Look at The Dumb Mistakes You Made
We all make silly mistakes all the time. However, sometimes we make mistakes because the things are not very clear. It is possible, especially if you are incorporating test doubles, that the test is just not correctly developed. Perhaps the assertion is not actually showing what you think it is, or perhaps you are testing a thing that is not required to be tested.
Here is the list of reasons your test might show red:
- You forgot to compile and save.
- The new test is not a portion of the present set of tests you are running.
- You are utilizing an outline that entails you to clearly add the test to a suite, but you overlooked
- You did not contain a real assertion in the test
- The test is deactivated
Therefore, this enables you to go back and check if you have made any dumb mistake and rectify it.
3. Sacrilegious the Rules of TDD
According to experts, you cannot write more production code than sufficient to clear you failing unit tests. The new entrants in TDD violate this rule promiscuously. If one statement would be sufficient to clear the test, they will introduce a new statement to protect against unsuitable input. If there is an expectation of the statement to be thrown, they will look for ways to handle the expectation. Although these are very good practices for programming, the appropriate TDD approach is primarily to document these unhappy cases by writing a failing test.
Experienced programmers frequently introduce hypotheses to back future generalization. Although an easier solution may exist to meet the requirements of the present test sets, these developers have a good sense of what is coming, if it is in the distant future or near. instead of this, you are required to go through a sequence of small test-driven increments, they elect to take a bigger step with a precipitately difficult solution.
