Comments on: TDD design trade-offs and junk food

By: Scott Bellware

Scott Bellware — Thu, 25 Sep 2008 20:14:56 +0000

> The interface is just a reflection of the language’s lowest
> common denominator of an interaction definition

A method table address and binding is the lowest common denominator of an interaction definition. An interface is just one way that can be done in one programming paradigm. And by paradigm, I’m not talking about OO, but static binding – which is ultimately a pre-optimization technique more than it is a design concept.

By: Derick Bailey

Derick Bailey — Thu, 25 Sep 2008 02:06:42 +0000

@bellware

re: why are contracts important

creating software that is understandable!

http://www.derickbailey.com/2008/09/25/AbstractionAndInterfacesWhatsThePointOfQuotclassFooIFooquot.aspx

By: Jimmy Bogard

Jimmy Bogard — Sun, 21 Sep 2008 02:33:37 +0000

@Scott

Re: why are contracts important:

When reducing interaction to solely the contract, C# allows me to control the contract to fine-tune the interaction to exactly what the behavior should allow. The interface is just a reflection of the language’s lowest common denominator of an interaction definition.

Interfaces helped move me beyond test-focused SoC that I started out with. Once I started looking at SRP at the interaction level, I feel like I started to understand what SRP was intending.

By: Scott Bellware

Scott Bellware — Sun, 21 Sep 2008 02:06:36 +0000

MotoWilliams,

> getting all the pieces together, all at once, just isn’t quite there yet

Taking small steps (very small steps), and doing one thing at a time is a non-negotiable part of the TDD regime. You’re bound to spend more time learning if you don’t take these two tenants very seriously.

I wasted a year on really fluffy TDD until I decided to take Kent Beck’s guidance seriously. When I realized JUST HOW SMALL of small steps TDD uses, and how serious is the admonition to do one thing at a time, things got better quite fast.

By: Scott Bellware

Scott Bellware — Sun, 21 Sep 2008 02:01:46 +0000

Ok, but why are “contracts” important? I can write concrete classes that interact with each other just fine without interfaces. And as Roy has already demonstrated, you don’t need interfaces for test-focused SoC. To wit, any concrete class’s signature is a contract with its user.

By: MotoWilliams

MotoWilliams — Sat, 20 Sep 2008 21:48:30 +0000

Your description of where you were is exactly the spot that I am currently at. I think I am going through a phase of thrashing, of sorts, which is frustrating because I know where I want to be but getting all the pieces together, all at once, just isn’t quite there yet.

However I do think that telling people to stop drinking Mt. Dew is just flat out irresponsible – what’s next no Tool or Deftones in the ear-buds?

By: Jimmy Bogard

Jimmy Bogard — Sat, 20 Sep 2008 20:37:02 +0000

@Sean

Just wanted to point out, it’s 58000K. That’s 58 million readers. Eat your heart out Atwood!!!!1

By: schambers

schambers — Sat, 20 Sep 2008 19:47:11 +0000

Well put Jimmy! Well worth your 58K readers =)

@Tony, probably the first and foremost benefit to TDD that I get across is the fact that you have a safety net when making changes to your code base. This in turn allows you to refactor your model when necessary rather than apply bandages (granted that your model is flexible enough), with minimal cost and damage.

By: Brian

Brian — Fri, 19 Sep 2008 14:37:49 +0000

If it can be of any helpful resource to someone, I wrote a post a while back about What TDD Has Taught Me So Far. I'm curious to know what this practice has taught you guys/gals so far as well.

By: Peter Beams

Peter Beams — Fri, 19 Sep 2008 13:49:21 +0000

I think that building better designed code is usually an unmentioned benefit of TDD. I’ve been using TDD for around a year now, and my design and pattern usage has come on leaps and bounds. My team’s code is more stable (because of the continual testing) and easier to maintain and extend (because of the improved design)