Building Block #1: Test-Driven Development from an Okie perspective
As I have stated before, I am no expert on this subject, yet. However, I am learning a lot about it and trying to put it into practice as much as possible. I am going to give a brief overview of how I understand Test-Driven Development (TDD) and then I will provide additional links and resources for you to further your learning.
What is Test-Drive Development?
As Kent Beck states in his book, “Clean code that works, is the goal of TDD.” Now you may be thinking why do I need clean code, it’s just me looking at it. And I say that doesn’t matter you may write a piece of code for a small little thing and come back to modify it in a year, look at it and think “What the heck did I do this for?” There are really only two rules for TDD:
- Write new code only if an automated test has failed
- Eliminate duplication.
These two rules imply an order of to the tasks we perform when we are developing software, this is the Test-Driven Development Cycle
- Add Test – Each feature begins with a test. This test will inevitably fail at first because the feature is not implemented
- Watch Test Fail – Run all tests and watch the new test fail, this validates the test harness and ensures the context you are writing the new test into is working.
- Write Code – You may have written a little code already, if not implement just enough code to make the test pass.
- Run Tests – Run all tests again, they should pass now.
- Refactor – Now the code should be cleaned up as necessary, we should get rid of any duplication that has been created in implementing the new test.
These are really the basics to TDD and I am trying like mad to force myself to do this every time I start to write a new piece of code. I write a test, watch the test fail, write some code, watch the test pass, refactor and restart the cycle over.
The biggest hurdle I had getting into this cycle and the one I still struggle with is, how do I know what tests to write? We still have to plan software and make user stories and development requirements right? The answer to that is yes, definitely, and guess what; we can develop our test lists from the requirements. Our unit tests should be very atomic so a single user story will most likely contain many unit tests that need to be developed and turned into a test list.
Hopefully I have shed a little light on the subject but in case I didn’t, here are some links below to additional resources: