Striking a balance with Test Drive Development (TDD)

I’ve been working with TDD for about 3-4 years now, and I still feel like it’s a wild-animal to tame. What I mean is, I have to keep in mind to strike a balance: write enough failing tests, one by one making them pass with logic pieces, and two: test only the basics and do your best to mock out other components and isolate their behavior from the test.

I do love it for the testing logical components of a solution and especially for embracing failure first and putting logic in place to get success. From a productivity-viewpoint, I would say generally using it only for mission-critical code and libraries, but not other areas that are more throw-away or don’t have workable test areas (small UI apps without heavy logic). I hope to come to understand the value in UI unit testing as I get deeper into MVC. Note: I haven’t been on the UI side as much in the past 5 years, and I gotta say, I’m missing not having some impact to the world in that way.

Others out there, what are your experiences with TDD and how have you overcome the challenges of avoiding testing the same thing over and over between tests?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s