How to shift your paradigm to Test Driven Development...

Question

I've had been hearing about test driven development for a couple years now and I never really paid too much attention to it from a practical level until recently when I started getting more interested in the .Net MVC. I've been playing around a lot with the MVC Storefront Sample and I am realizing just how cool and helpful that Test Driven approach can be. However, I've been programming using a "test last" approach for a long time now, and when it comes down to business, I can always best estimate my effort with the approach that I am most familiar with.

I'm guessing that learning how to use the Test driven approach is less like learning another programming language, but more of a change in how you approach laying the framework for, and planning the requirements for building an application. I don't think I could just pick up a book and start a project for one of my clients using TDD, I'm guessing my introduction to it need to be more methodical.

So my question is what is the best way for me to shift my mind-set of planning to build an application so I can become effective with Test-driven development in the shortest amount of time?

Answer 1

You can still test last. It's okay. We'll forgive you.

Learn how the unit test tools work in your current language.

Start writing unit tests for whatever you're working on now.

Eventually, you can move to code-a-little-test-a-little. Then test-a-little-code-a-little.

Pure test driven development is an ideal. Pragmatically, most folks test-a-little-code-a-little. More like test-steering or test-guided, rather than test-driven.

Start now. Test anything you have at hand.

Answer 2

In addition to what S.Lott says, look at how MVC Storefront is structured.

How do they handle testing with data that comes from a database? How do they handle testing that the Controller operates correctly? How do they handle when a class has other dependencies?

Looking at how TDD requires you to structure a program will really help, once you've got past the basics of (???)Unit

Answer 3

Even if you're writing code first, ask yourself as you write it, "is this testable?" If it isn't, then you might want to rethink your design for the particular piece of code you're writing. If it is, then go ahead and finish it and write some tests afterward. I'm in the code-a-little, test-a-little mindset myself right now.

Answer 4

You need to practice.

You can start with Test-First-Programming. Design the code just as you usually do, perhaps not in deep details, and start implementing it test first: start with a class that has no dependency, see how it can be tested, write down a list of the tests you can think of. Start writing the simplest test. Then write just enought code to make it pass. Cross the test on your list and write it, write the code.

When you have an idea for a new test or ask yourself a question about how the code behaves under certain condition, add a new test to your list.

I'd recommend you read Test Driven Development ; it's a very good introduction to TDD and also contains a lot of reference materials (called patterns).

Regarding the estimates, one thing to keep in mind is that although writing the code and the tests simultaneously is slightly longer than just writing the code, you end with code that works.

Some more advices, once you'll get started:

Add a new failing test before to fix any problem in the code.

Strive never to write any line of code without having a failing test - that's the ultimate goal.

Answer 5

The best way to pick up TDD is to go ahead and do it. That's the only way so far I've manage to get co-workers "test infected" - at least right now you have a good appreciation of the benefits upfront.

From a more practical point of view though, I think you already have highlighted one of the key ideas - it's a change in planning the requirements for building an application. Whatever methodology you're currently using, if you see a word like "requirement", you can mentally think "test case", and at least have the intent of writing the test case first. But just like the other answers suggest, TDD isn't an all-or-nothing decision. Any test you write, whenever you write it, before or after, is helpful. Likewise, don't think you can ever get to a state where you write all the tests upfront - it's a cycle.

A favorite of mine is the pseudocode iat the end of this item in the JUnit FAQ. The test case frame of mind is an infinite loop. Jump in anywhere, any test you write will help, and you won't regret it.

Answer 6

I don't see why you couldn't just start using TDD. You don't need to create all your code using the practice - just use it for one class a day, or one hour a day, for starters. When you get more comfortable, extend the application of the practice to more of your code.

Also remember that TDD is more of a design strategy than a testing strategy. Be open to what the tests are telling you about the production code. Always refactor mercilessly - especially at the beginning, err at the side of too much refactoring, if in doubt.

If you can find some likeminded people, consider conducting a coding dojo; it's a great, fun way to learn a new programming skill: http://codingdojo.org/