It’s amazing how many decisions we make in the course of developing a feature:
– How should this work?
– what does a developer need to call this method?
– What other parameters should we add?
– What should logging look like?
– How do we add new capabilities to this feature?
– Where should we store settings for this feature?
and on, and on, and on.
The cognitive load itself can be a bit heavy, and then there’s what can happen when you mix the features together. It starts to look like spaghetti if you aren’t careful.
One of the wonderful things about TDD is that it can help you make those decisions and it can show you the impact of those decisions far faster than implementing logging or setting storage or how parameters get added if you hadn’t had tests in place.
Without TDD, you have to implement a feature in at least two out of three layers of your application: either UI and Code, or Code and Database. With TDD, you take that time and you cut it down to just code.
That’s pretty remarkable, and can help you make decisions faster.
I’m covering this (and more) at the free webinar on March 5th, titled “Intro to TDD For .NET”. We’re not going to spend much time on the mechanics of TDD, rather we’re going to spend the time showing how TDD can actually help you. If that’s interesting to you, sign up here.