Step 2. Test fails: Of course, the test fails because
you haven’t written the part that works yet. The
idea here is to think about the class or function
you want and test for its intended output. This
initial test failure shows you exactly where you
should focus your code writing to get it to pass.
This is like starting with your end state in mind,
which is the most effective way to accomplish a
goal.
Step 3. Write some code: Write only the code
needed to make the new function or class
successfully pass. This is about efficiency and
focus.
Step 4. Test passes: The test now passes, and the
code works.
Step 5. Refactor: Clean up the code as necessary,
removing any test stubs or hard-coded variables
used in testing. Refine the code, if needed, for
speed.TDD may see like a waste of time initially. Why write
tests for stuff you know isn’t going to pass? Isn’t all of
this testing just wasted effort? The benefit of this style of
development is that it starts with the end goal in mind,
by defining success right away. The test you create is
laser focused on the application’s purpose and a clear
outcome. Many programmers add too much to their code
by trying to anticipate future needs or building in too
much complexity for an otherwise simple problem. TDD
works extremely well with the iterative nature of Agile
development, with the side benefit of having plenty of
test cases to show that the software works.
UNIT TESTING
Testing your software is not optional. Every script and
application that you create have to go through testing of
some sort. Maybe it’s just testing your syntax in the
interactive interpreter or using an IDE and trying your