Last night I had an AH-HA moment.  It finally hit me and made sense.

1.  Red

2.  Green

3.  Refactor

Sounds obvious, but I really was not thinking about that part of the TDD process correctly.  First, the test needs to fail.  Write the unit test the way you want to read it. I think this is a critical step when you first start out.  Even if you know it wont work, you want to validate your assumption.  Second, you need to make the test work.   Get the code to compile.  Once it is green, you begin refactoring it to work correctly.  This is where you would add the actual logic and make your database calls.

My current project required me to read from disk a certain cs file in a test directory.  The test class had one method.  I made the test work by hard coding the 1.  That is how I was able to get to green quickly.  Next in the refactoring step, I actually added the code.  The code uses a regular expression parser that I am writing from scratch.  While I was implementing the logic, I kept my eye out for design changes and duplicate code I could remove.  These refactoring steps need to be related to the current test.  If the refactoring does not relate to the current test, then you need to add them to the test list.  Stay focused.  I know developer ADD can be bad.

I have to say again, it is a pretty awesome feeling knowing you can go in there rip out the guts, delete methods, rename things, and you have backup to tell you when you messed up.  It worked the way it was supposed to before you started.

I will keep adding posts as I move through the phases of this project.  It is requiring a large amount of research to find better methods.  I am going to keep the posts fairly frequent.  This is both for a learning perspective, and so I do not forget to document any hurdles.  I love AH-HA moments.

Code Happy,

Bill