We're excited to be offering a new course, Pragmatic Test-Driven Development, with a practical bent to testing. Test-driven development (TDD) traditionally means writing unit and acceptance tests along with production code. Some agile thought leaders push a hardnosed test-first practice, insisting that you always write a failing test before you write any production code. Then, in short programming and testing cycles, evolve your test as you complete your code.

One common objection to TDD done this way is that writing tests this way doesn't seem "natural". Instead, you may want to write a coherent chunk of code before writing any tests. We agree with that. In our course we explore several different ways you can do Test-Driven Development, making TDD much more approachable to a wider audience. We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don't insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some tests first, and use those test scenarios to guide them as they write code. Once they've completed a "good enough" implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don't write hundreds of lines of code without any testing, we think this style is OK too (and we don't insist on one style over the other).

As long as you check in your production code along with unit tests that pass, your programming is being "driven" by tests.

We believe that it's not so important to test first as it is to test frequently! Testing should be integral to your daily coding and design rhythms. And your production code should only be checked in along with its passing tests.

There's a lot more to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. And acceptance tests, smoke tests, integration, performance and load tests support incremental development, too. If all this testing sounds like too much work, well, let's get practical. Testing shouldn't be done just for testing's sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system.. That's why it is important to know what to test, what not to test, and when to stop testing.