Red, Green, Refactor
This page is a stub, and is awaiting more content from a community hero. You could be that hero.
Red, Green, Refactor is a work pattern used in Test Driven Development, which describes the test outcomes as the code is developed.
First, write the tests; they will fail ("red result"). Next, implement the feature, and gradually the tests will start passing ("green result"). Finally, clean up the code by de-duplicating and applying other re-factoring practices; with each change run the tests again, and so long as the results stay "green", you know that you have made a valid re-factor without introducing errors.
The transition from beginning work to the Red phase provides the specification for the feature. Each (failing) test that is written specifies the features and behavior of the software.
Next, the transition from Red to Green provides the gradual implementation of the feature. Each feature is implemented in the simplest, most straightforward way possible - code only enough to get the code to pass the test (YAGNI).
Finally, the transition from Green to Refactor is enabled when all tests pass. Because all tests pass as a baseline, you can now safely refactor the code - as you introduce a code change, you can rely on the tests to detect regressions. Refactoring is important to remove code duplication (DRY ) as well as to improve code maintainability, such as meeting a Coding Standard.