My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Because when you don't, how do you know your change to the code had any effect?

When a customer calls with a trouble ticket, do you just fix the problem, or do you reproduce it first (a red test), make the fix, and test again (a green test, if you fixed the problem)?

Likewise, if you write automated tests, but don't run them first to ensure they fail, it defeats the purpose of having the test. Most of the time you won't run into problems, but when you do, it's not fun trying to solve them. Who would think to look at a test that's passing?

The solution, of course, is to forget about testing altogether. Then we won't be lulled into a false sense of security. Right?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

I was drawn to this post by the title and I like what you're saying Sam. I hope you'll pardon a shameless plug, but it's right on topic, so...: I just (a few days ago) put up a step-by-step on how this test-red-green-test cycle looks in action. it's at http://mxunit.org/doc/index.cfm?doc=TDDExamplePlug...

Posted by marc esher on Jan 30, 2008 at 09:41 AM UTC - 5 hrs

I don't mind at all. The only time I do mind is when it's completely off topic and irrelevant.

MXUnit looks quite well documented, so kudos on that!

Do you have a page explaining the differences from cfunit and cfcunit (ie, "Why you would want to switch")?

Posted by Sammy Larbi on Jan 30, 2008 at 10:25 AM UTC - 5 hrs

I know from my own experience that development goes more smoothly when I have lots of tests. So what is going on when I find myself reluctant to write them and wanting to get on with solving the problem? [It's like we know procrastination, eating bad food, ... aren't good for us, but the pressures in those directions tell us something.]

So here's what I see as pressures in the wrong direction.

1 I don't know what the API will be like until I have some sort of solution modelled.

This points to how we think about problems, as well as the language shaping how we think about how to tackle the problem (else the language isn't worth learning [Perlis]), the objects we can create shape the solution. And there are lots of ways to do that, including many incorrect ones [e.g. design pattern abuse.] Are there tools to help with this (that can be versioned easily, and aren't so heavy as UML?) Can testing be applied to those conceptual models as easily as to XUnit supported languages?

2 The language doesn't naturally help me organise the tests.

C doesn't have an object to use as a unit. It also doesn't have exception handling, making tests less prone to really torture the code. Except there are C torture tests. I've got stuff to learn in this area, clearly. Can tools like Ruby Inline help, where C code can be embedded in Test::Unit code? I've only just thought of that, so I don't know.

3 How can writing the tests help you create the model, and create something cohesive?

Clearly they can result in a more componentized API, because if a system is untestable, then it is widely regarded as being in need of refactoring to make the code solid. But in terms of helping one design the underlying mechanisms, is there evidence that test first helps create the right set of objects? How does this factor into not being able to see the progam (==wood) for the methods (==trees)? Newcomers to OO have been known to complain about this kind of thing, not being able to see the program for the objects -- "which bit actually does something?" Are there testing practices which drive one in the direction of a good cohesive model?

I wonder if there are other factors people can think of.

I'm hoping that as Rubinius develops, and handling Ruby with Ruby becomes easier, then things like Autotest will be able to write more sensible code inside the test harness it roughs out. An automatic
code critic could help ease what pain there is in writing the tests, to some usefully limited extent.

Posted by hgs on Jan 30, 2008 at 10:54 AM UTC - 5 hrs

Thanks Sam. There's another newer article I put in there on TDD for new functionality, too, and it's loaded with screenshots.

We haven't written any "competitive" documentation like that. Hell, we haven't even "announced" mxunit to the world, so to speak. we've had it in alpha forever, mostly because we keep wanting to add tweaks here and there. but i think an RC release is coming soon which will probably look exactly like it does now, if for no other reason than we're trying to focus on documentation now and keep our paws off the code. bill and i are presenting on TDD at webmaniacs, and since we've been busily preparing for that it has actually given us an opportunity to let the code sit, which is a good thing.

we'll probably put something on the site about "why we built mxunit", and that'll touch on the differences in frameworks. It'll be up to bill, really (bill shelton started mxunit). so i'll see what he has to say. I doubt, though, he'll want to put up a head-to-head comparison out of respect for cfunit and cfcunit. we're standing on the shoulders of giants, really.

Question for you, related to the topic of TDD and not framework-specific at all: What do you find hard about TDD? When you're developing and you see yourself not writing tests but jamming out code, what causes those moments for you? And have you really, in all honesty, ever reaped significant benefits either in productivity or quality from unit testing? Because there's a pretty large contingent of folks who don't get much mileage out of TDD, and I can see where they're coming from.

Thanks.

Marc

Posted by marc esher on Jan 30, 2008 at 10:54 AM UTC - 5 hrs

@hgs - I don't often worry about item 1, because although as you say the API is unknown, it develops from the testing and many things are easy to manipulate as you see a need to change the API.

For item 2, I like the idea you have to use inline C within Ruby. I don't do anything in C at the moment, so I have no need to test there, but it's an idea I'd certainly try if/when I work in C again.

As for item 3, I /feel/ testing has helped me in that area, but I have no real evidence of it to share. It certainly helps me keep my methods cohesive, and I try to create new objects as I see a method making the class less cohesive. But I have a hard time remembering what it was like in the beginning, except for confusion about it all.

@Marc - Good questions. I'll come back to that hopefully next week with a new post, because there are a lot of things I'm uncomfortable testing (and where I think I'd be uncomfortable if I were to venture), so I'd like to explore that in a bit more detail in a post as opposed to a comment. Likewise, the benefits I see would be a good topic in that same post.

Posted by Sammy Larbi on Jan 30, 2008 at 12:27 PM UTC - 5 hrs

Michael Feathers just posted an article on unit testing in C at http://beautifulcode.oreillynet.com/2008/01/when_c...

Posted by Sammy Larbi on Jan 30, 2008 at 04:11 PM UTC - 5 hrs

Sam, i wanted to let you know that we put up a brief doc on our site on "why mxunit". Again, it's not competitive. Mostly it highlights what we believe are the important features of the framework.

cheers.

marc

Posted by marc esher on Feb 06, 2008 at 03:21 PM UTC - 5 hrs

Great! Thanks Marc. Sorry I didn't get to that post this week, will try again for next!

Posted by Sammy Larbi on Feb 08, 2008 at 04:05 PM UTC - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and C++ (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner