The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Discussion on unit testing, TDD, etc.

The joel podcast post really got me thinking about unit testing and TDD.

I asked a question on stackoverflow.

http://stackoverflow.com/questions/513778/what-do-you-think-of-junit-style-unit-testing-do-you-favor-behaviour-driven-test

Charlie had the most interesting responses:

"Okay. There are a couple of points here. The first one is that you want to use TDD tests that tell you something interesting; there's a limit to the number of those tests. In your case, you wouldn't want to write all of those tests unless you believed, for some reason, that the case of add(2,2) was going to be significantly different from the case of add(1,2). Since the simplest thing that could work pretty quickly will be to define int add(int a, int b){ return a+b; }, the return on investment on those tests rapidly diminishes."
berlinbrown Send private email
Thursday, February 05, 2009
 
 
I'm admittedly not a fan of TDD. As Charlie points out the tendency is to write a single test that works (and one that fails) and that is usually the most obvious things that you would normally do unit testing for anyway. I realize that TDD is not about writing thorough tests. TDD is more about hashing out requirements through writing tests. But even for automated testing I see the same thing. People write the most simple tests that you would unit test for anyway.

If you want to have valuable tests, test for as many edge cases as you can. In the example of the add(a,b) method you need to at least test for overflow scenarios. But even that only works for very well defined, simple methods. It doesn't work for complex interactions between layers or different parts of the system. And THIS is where 90% of your bugs are anyway.

The simple add(a,b) method will be written once and tested once. And then you'll be done. There is virtually no value in writing tests for code that will never change again. And if it does change, it is simple enough to retest and then put back to rest. Yet these are the types of methods that everyone writes tests for. Why? Because they can. The really hard stuff that needs tests never get tests because it is just too hard to come up with automated tests that cover even a tiny fraction of all the possible problem cases.
dood mcdoogle Send private email
Thursday, February 05, 2009
 
 
I think Joel is bothered by the Architecture Astronauts again. And rightly so. Architecture is important. But not all that is important is architecture.

A common misunderstanding about design-by-contract (DbC) is that the coder defines the contract by writing it into the interface specification(in languages that support DbC like Eiffel, D and Spec#). Not so.

The *code* defines the contract. What the programmer writes into the API spec is *a declaration of what he understands the contract to be*. (And DbC-enabled languages then proceed to field-test that understanding...)

Unit tests perform a similar service -- actually complementary: if the API is the "envelope" of the class, then contracts constrain it from the inside, and unit tests constrain it from the outside. When you have eliminated all wiggle room between them, you truly know how the software will behave.

So unit tests are essential -- FOR UNITS. But not all software subcomponents are units. What is a "unit"? Following the architectural metaphor, IMHO a unit is a well-known, standard, reusable load-bearing structure that will appear in many different buildings simply *because* it is known to reliably do that particular job.

But real buildings in actual use also contain facades, entryways, signage, movable furniture, wastebaskets, and so on -- things temporary, one-off or non-mission-critical. These don't *need* the engineering guarantees that the central pillar does.

And, if one of these items is later re-purposed to more general application, you can write the unit tests for it *then*. Indeed, I often write contracts for legacy code to help guide (and test) my understanding of its behavior.

I got nothin' against architects. But like many of us, they tend to dismiss anything outside of their specialty as not being quite real. Truth is, you need architects to build a building... but you also need ol' Benny with his overalls and drop-cloth, who knows when all you really need is a big daub of schpachtle right THERE.
Davidson Corry Send private email
Friday, February 06, 2009
 
 
p.s. As an architectural example of why some things are better left not reduced to units, I nominate those never-sufficiently-damned corporate cubicle wall-systems.

'nuff said.
Davidson Corry Send private email
Friday, February 06, 2009
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz