From: Sean O'Dell <sean@...>
Date: 2004-06-07T04:47:58+09:00
Subject: Re: How to ducktype a Hash?

On Sunday 06 June 2004 12:08, John W. Long wrote:
>
> I have only a small amount of experience with using Ruby on large
> projects, so maybe some others can chime in here. You said earlier that
> you were not using unit tests any more because they seemed like too much
> work, but they did not save any time in the debugging game (forgive me
> if I have misquoted you). I wonder if what you are finding is that Ruby
> w/o Unit Tests is much harder to use on large projects than Ruby w/ Unit
> Tests.

No.  As the project grows, errors crop up in new places.  Unit tests only help 
if either a) you can anticipate where the errors are going to occur or b) 
errors keep coming back to the same points in code where you've put unit 
tests to debug the bug originally.

a) When I can anticipate errors, I prevent them on the spot.

b) When I fix a bug I didn't anticipate, only EXTREMELY rarely will it creep 
back in.

So neither in case a or b have unit tests helped me.

I've NEVER been able to anticipate errors that I couldn't anticipate (think), 
so writing a bunch of unit tests in advance never found me a single bug.  
They super rarely re-occur, so writing unit tests when debugging has never 
helped me there either.

Back when I used to write unit tests, I used to let myself "pretend" I didn't 
see certain kinds of bugs coming, and I would writing unit tests, and then 
cheer when the tests found them.  But after awhile, I came to realize that I 
was perfectly capable of anticipating them, so I would correct my code before 
they happened.  Unit tests became completely useless to me.

> Type checking is a form of unit testing (only in most cases it occurs at
> compile time).  Languages without type checking often need another form
> of testing. Unit tests help automate the process of exercising your code
> making sure nothing has broken. This gives you a level of confidence
> that allows you to refactor mercilously. Without unit tests I can
> understand why you would find Ruby frustrating.

Type checking and unit testing are not the same thing at all.  Unit testing is 
a develop-time only event, and even then you do it sporadically.  Type 
checking is done at run-time.

I have this thing where I automatically start to de-value a person's opinion 
when I detect "unit test evangelisation."  I've done a lot of unit tests, and 
I've written my own framework, and I've used them on large and small 
projects, and they eat up time and don't help me catch any errors I couldn't 
already anticipate.  Whenever someone tells me unit tests help them a lot, I 
have come to assume that anticipating bugs must be inordinately difficult for 
them.  I simply don't have that sort of trouble.

> I have a tendency to believe that small projects are doable in Ruby
> without unit tests, but larger projects require some form of automated
> testing.
>
> I'm curious, is this generally true for all dynamic languages? Should
> unit tests be a requirement for large projects?

On large projects, way before unit testing reared it's fanatical head, you 
always had to develop tests to check interfaces between large components of 
the project.  That wasn't so much for debugging as much as checking 
compliance among the APIs you develop between large components.

	Sean O'Dell