Learning TDD, BDD

In the last couple weeks I have dived head first into automated testing, specifically Test Driven Development or TDD. It's been quite the journey so far. At first TDD concepts seemed hard to grasp but a balance of reading and video began to bring it together for me. For example the idea of only writing code to fix a failing test is a hard one to grasp when you have spent almost 3 years developing code without even thinking about a test. It was hard to think in terms of what a "unit" test is not. Borrowing from Michael Feathers blog:

A test is not a unit test if:

It talks to the database

It communicates across the network

It touches the file system

It can't run at the same time as any of your other unit tests

You have to do special things to your environment (such as editing config files) to run it.

Writing tests around legacy code is another big challege. Being that my project is defined as legacy code because it doesn't have unit tests, I have the task in front of me in getting it covered by tests. It won't happen without quite a bit of refactoring!

I watched a video on Behavior Driven Development or BDD. It is essentially doing TDD well. The focus of BDD is focusing on testing the behavior of a system not necessarily having your tests mirror the exact structure of the classes you are testing. In this way your tests become the specification for your production code.

Here are some points/tips I've observed:

• Testing first helps you to think critically about what you are trying to write.
• It is impossible to know everything upfront. Do what you know now, thinking decently far in context but not to far.
• Don't over engineer.
  
• Agile & TDD allows for tight collaboration with the customer... a good thing!
• Tests are the "glue" that holds an application together.
• Unit testing is testing the smallest components which are classes/methods.
• Customer is in control which is very motivating for them.
• Solve the RIGHT problem RIGHT!
• Over the long term effort required to write tests will pay off vs having to maintain untested code.
• Developer can feel confident about work.
• Refactoring is changing structure without changing what the code does.
• Keep unit tests as simple as possible.
• Tests are atomic and isolated.
• Create "test list" from requirements, from this we can know if we are "there yet".
• Tests are like examples.
• Concentrate on testing the behavior of your program not necessarily mirror the exact structure of the class you are testing.

All in all I believe TDD is a superb idea and a process I am adopting in my projects.

Life Update:
In my last blog post I wrote about moving and pursuing a degree. We arrived in Gosport, IN on August 4. Originally I was planning on starting school on Sept. 1 but since our apartment was not quite ready I pushed it off another month. So I am scheduled to begin my degree program on Oct. 1 with WGU.