How to shift your paradigm to test-driven development

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.

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 its test first: start with a class that has no dependencies, 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 enough 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 advice, 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.

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/

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