test driven development


first we would need use stories!

Then, following Process should be followed

Follow these steps (slight variations exist among TDD practitioners):

1.Understand the requirements of the story, work item, or feature that you are working on

2.Red: Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed. You will not get IntelliSense because the new method does not yet exist.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.

3.Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.
If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. The test is the objective definition of "done." The phrase "You Ain't Gonna Need It" (YAGNI) is often used to veto unnecessary work. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.

4.Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles.