Posts
1150
Comments
891
Trackbacks
1
More on TDD

Dimecasts is a site created and run by fellow Chicago Alt.Net group ‘founder by which we mean we were in the bar when we decided to do it’ Derik Whittaker that hosts a decent number of relatively short webcasts on topics that Alt.Net type people might be interested in.  They are supposed to be all under 10 minutes, but as I like to heckle Derik about, it’s usually 11 minutes up to about 15 minutes.  No matter, really, but heckling is fun and cheap.

Anyway, Episode #65 is a ‘demo’ of sorts of both TDD and Pair Programming, as Derik and Kyle Baley begin to implement a basic new feature for the Dimecast site, one which will email the author of a Dimecast episode any comments that are added to it (the site already allows comments).  So, pretty basic stuff.  Kyle (whom I have exchanged email with on occasion but don’t know anywhere near as much as I do Derik) is remote, so there is lag and some static in the webcast, blah blah blah, but the production values aren’t really important, as the two are able to do what they want to do, and it is easy to follow.  And taking 15 minutes to test out a design for a feature seems like a decent amount of time to do it, so no worries there.

Having said that, watching this webcast, it worries me that any competent developer who might see this will reject TDD out of hand.

To put in a few caveats/disclaimers about what I *don’t* mean by this:

- as my own hobo-like presentation at the Chicago Alt.Net group will attest to, I embrace the idea of programming to interfaces, so the fact that there are four interfaces in the design doesn’t bother me.

- while I personally don’t have a love affair with the underscore naming convention, I understand how the sorts of reports that can be generated off of them can be much easier to understand in various situations, so that’s cool.

- rap master douchebag hasn’t issued any ultimatums about this episode, so I assume it is at least a reasonable presentation of TDD in this space.

Having said all that, there are obvious problems here.  The piece of functionality under test is that an email is sent to the author of an episode if someone comments.  As designed, the test requires *8* vars to do so.  Each ‘var’ is a place for possible error and often requires a proper understanding of the mock framework.  That’s a hell of a lot of code required to test a single assert.  Imagine if the requirement was actually difficult.  Related to this, the code in the test has basically no semblance to the code that will actually perform the functionality as required in the *real* code (which hasn’t been written yet, but will be in the next episode, numbered whatever).

From a philosophical standpoint, <insert gratuitous comment>I have multiple degrees in Philosophy, the core of which involves logic</insert gratuitous comment>, TDD makes a lot of sense.  What is my code supposed to do, and what is its API supposed to be?  Great.  But, maybe it is the syntax, maybe it is the process, but the fact of the matter is, if I really want to know if an email is sent when a comment is added, I can write 10x less code and just run an integration test.  “OOOO, integration tests are slow!!!!!!”.  Sure (though I immediately want to ask, compared to what, and what’s your confidence that your 74 vars in your test code actually test what will happen in production??), but slow is better than inaccurate. 

It is easy to get addicted to the fast results of unit tests.  If you’ve ever had to switch between them and long-running integration-style tests, it is *painful*.  Extremely so.  But integration-style tests, when done properly, test your real code, not some ‘hopefully accurate’ code.

posted on Friday, November 21, 2008 8:19 PM Print
Comments
Gravatar
# re: More on TDD
Kyle Baley
11/22/2008 8:15 PM
I can give you some stock responses on the benefits of TDD but they'd be hollow and you've heard them all before. It wasn't that long ago that I had the same concerns (http://kyle.baley.org/ConscientiousCodingIsTheNewTDD.aspx) and in more than a few ways, I still do.

In the end, I lean towards it in large part because it just feels better. Call it developer intuition or call it job security, in my limited experience, I like the results I get with it more often than not.
Gravatar
# re: More on TDD
Derik Whittaker
11/22/2008 8:32 PM
John,

First thanks for watching and all things equal thanks for the good comments.

In terms of the value between unit and integration we never said anything about integration and our goal was not to slam it. In fact i am a believer in integration test, but they have their place.

The entire concept of the video was to show how you could create a feature with TDD. We just happened to do it why creating a unit test. We just as easily could have done it building an integration test, but we did not.

What does suck is you slam the 'failures' of 'unit tests', but you did not talk to the failures of 'integration' tests. To be fair an non-Fox News like talk to both sides of the testing story so your readers can hear both sides of the story.

Do the right thing and give informed information on both sides of the story instead of just slamming one side.
Gravatar
# re: More on TDD
jdn
11/22/2008 9:09 PM
@Kyle

I understand the idea that TDD can produce better results in the long run. But in this example, how are your presenting this?

I know it sounds harsh, but I find it hard to believe that any talented developer would be convinced of this from this webcast.

TDD makes a lot of promises. The fact that it takes 8 vars to test even the most basic of functionalty calls those promises into question.
Gravatar
# re: More on TDD
jdn
11/22/2008 9:22 PM
@Derik

You have made the ignorant remarks on your blog about how you can only produce quality code by using tests. No one with intelligence would accept this, but you can't then produce a webcast that is as poor as this one was, and then try to change the subject about integration tests.

The unit test you created required 8 vars. Are you debating this? I don't think so. The ways in which integration tests are subject to failure is interesting, but irrelevant to the point of my post. I'm not sure why this needs to be explained.

Since it seems to be hard to understand, let me make it clearer: any intelligent developer who didn't already subscribe to TDD would be turned off it by your webcast, as any integration test would actually test the functionality you are creating, while your TDD example requires a *ridiculous* amount of work.

People who think it 'cool' to insult others concerning quality need to look in the mirror a bit more, IMO.
Gravatar
# re: More on TDD
jdn
11/23/2008 12:00 PM
On the other hand....

Bellware's complaint about AutoMockingContainers was that they hid dependencies.

If you looked at it in that light, one could view the dimecast as a way of exposing the need to refactor your design (because it requires 8 vars to do one assert), in which case you are highlighting one of the benefits of TDD.
Gravatar
# re: More on TDD
Kyle Baley
11/23/2008 5:53 PM
I think it would be hard to convince any developer from watching TDD being done in short bursts, regardless of talent. I felt the same way watching JP's dnrTV episodes on it.

I may have assumed wrong but my intent was to show how, not why. I'll leave that part fo others 'cause I don't like subjective arguments. They always seem to degenerate into accusations and accusations of accusations. I'm sure I can find an example around here somewhere...
Gravatar
# re: More on TDD
jdn
11/23/2008 6:07 PM
@Kyle

LOL. Well said, touche.

One of the reasons why I am so annoyed at Derik is that I don't mind being called stupid. And I don't mind being called lazy. I do mind being called stupid and lazy. And that's what I get from his recent posts about testing.

Bitching aside and more to the point, it isn't so much that I don't see how this dimecast would convince anyone to do TDD. That is an unrealistic expectation, as you mention.

But, I do think that people learn about techniques in different ways, and watching webcasts of any sort is one way to do it. I've downloaded every single Dimecast, and watched about half so far (including some of yours). This is the first one I ever watched where I wondered about the content.

Since Papa Smurf hasn't demanded any apologies, I assume that this is a decent way to do TDD (as best can be described in 15 minutes), but it seems so wrong to me. I'm forcing myself to do (what I think is) TDD on a project and it isn't like this, and if it was, I would be discouraged.

What do *you* think about having to have 8 vars to do one assert? Doesn't this strike you as....something?
Gravatar
# re: More on TDD
Derik Whittaker
11/24/2008 9:27 AM
@JDN,

Now sure where you get off saying that I am calling people stupid in that post? I do call them lazy because 'I' believe that if you do not write tests (notice I said nothing about unit/integration) then you are lazy. WHY are you lazy? Because 'I' believe (from experience) that testing improves quality and you are lazy if you do not do everything you can to improve quality.

The fact is people/developers are lazy people (myself included) if they were not lazy they/we would not produce such shit code (test or not tests).

As for having 8 var's, not sure i see your issue there. If your goal is to minimize the number of vars you use/create then you are trying to solve the
wrong problem.

BTW, using comments for this type of conversation is just bad, if you want why don't we all setup some time to skype about this?
Gravatar
# re: More on TDD
Kyle Baley
11/24/2008 10:54 AM
I've been avoiding mention of the number of variables because I had long forgotten the code. In general, I don't see anything wrong with it. If that's what is required to implement a function, then so be it. You've no doubt heard this before but we're driving out design. The tests are a bonus.

That said, let's look at this as a code review. You say eight vars is a lot to test the functionality we built. After reviewing the episode, we aren't really using the episodeRepository or sponsorshipRepository. We could pass null for the latter. Not so much for the former, though I suppose we could get rid of it with an AutoMockingContainer since we aren't actually testing any functionality against it.

The rest of them look okay to me. I suppose we could remove the emailAddress variable and use the constant "moo@cow.com" bringing us down to five with an AMC but I feel a little silly doing it just to reduce a variable count.

You could just as well ask why we need to create so many dependencies in the first place. I remember wondering that myself with TDD. Don't know what to say. TDD leads to lots of classes. Just need to push past the gag reflex *if* you see enough value in the methodology.
Gravatar
# re: More on TDD
rscot231
11/24/2008 12:42 PM
@Derik:
Comments are an awesome forum for this type of discussion, because otherwise the rest of us wouldn't have the enjoyment of listening in on the argument.

Gravatar
# re: More on TDD
jdn
11/24/2008 7:07 PM
I'd be more than happy to Skype it (that sounds dirty). Where is Kyle these days? Bahamas? Calgary? Sweden?

@Derik
Yes, technically you don't use the term 'stupid', but that's a technicality. You really think that there was never any quality software written in the Microsoft before automated testing? It took you and me and all the other alt.NET happy fun circle jerk gang to come along and teach the unwashed masses?

Now, you probably wouldn't phrase it that way, but it is basically what you are saying. Like at the last Chicago Alt.Net meeting, there's this tendency to contrast software development between 'our high quality tested stuff' and (and this is almost verbatim) 'that combo VB6/Excel app written by the Executive Secretary.'

I can out-elite, out-arrogant *anyone* (as some may have noticed) if I put my mind to it. Forget the Ph.D stuff, I have obnoxious arrogance cards I haven't even dealt yet.

And I know what it is like to deal with really stupid/ignorant/difficult developers (besides myself) who don't have a clue. I get all that.

But I guess this just shows that I actually care what goes under the rubric 'Alt.NET', and this dumb high-school clique like elitist arrogance is annoying.

*Especially* since it is possible for testing to make code *worse*.

@Kyle/Derik

If you don't get why having 8 vars to get one assert (what happens when you need to test code that actually does something significant? Will you need 17? 42?) might possibly be a problem.....it doesn't *have* to be, and as Kyle whittles it down to 5, and maybe less with a refactoring or two, maybe it no longer is, but since you don't have tests that test the tests, every line of code you introduce in your tests increases the chance that your tests are faulty.

Like I've stated previously, empirical studies show that test code has the same amount or more bugs than the code it is testing.

I agree with @rscot231's sentiment, but I'm open to Skype. Might be more efficient in some ways.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 4 and 1 and type the answer here: