David Chapman's Profile

It certainly does slow down your development speed up front, but once you get into the flow of it, ensuring that your entire code base is covered with tests is absolutely invaluable. Especially when you are working on a large project or just coming back to an old one. The amount of time that is saved from debugging is more than the time that is spent writing tests.

Of course, it is all about finding the balance that works for you. It's just a matter of trying it out for long enough to actually experience the benefits of it.

the issue is that the episodes would be too long, and it would muddy whatever else I'm trying to teach. This is why I opted to keep the testing episodes separate.

I totally understand the issue of length for each episode. Having an episode focused on building a feature then having another focused on building it with TDD seems like a great approach. It avoids the issue of length and gives you the time to focus on both aspects (functionality and testing) adequately.

Great screencast! Having been passionate about testing, yet being totally self taught, it is great to see the similarities and differences in our testing process.

One thing I am curious about is: What do you think about the approach of having only one assertion per test? I have read quite often that people take this approach in TDD, but it seems like, at least when writing request specs, the responses from a failing test make it very clear which assertion failed. Perhaps this is better practice in model specs?