Hi

I have a good friend from Turkey.
You've moved farther than him, he still clings to Perl and thinks
$%; help readability. But other than that, you have a lot of  
similarities.

He has no time for unit testing. The reason? He's too busy fixing bugs.

On May 7, 2006, at 6:18 PM, Talha Oktay wrote:

> I would like to comment against posts which simply emphasizes that the
> interpreter can not think for us. I know that of course. What if we  
> could
> tell the interpreter by saying that these are the variables that I  
> am going
> to use in the class scope, in a block, in a method or in global  
> scope etc.
> and ask the interpreter not to allow any other variable usage in the
> specified scope?  Then the interpreter would definitely know our  
> intent? I
> meant that.

One could do this. I'm not sure of the performance hit though. Probably
wouldn't be used by experienced Rubyists.

> much as I expected. Yes I develop faster, but I lose the time that  
> I gained
> in coding in testing. I prefer testing the functionality and the
> requirements not the guts.

Are you sure? You need to consider the aggregate of time wasted
by your users and yourself from releasing bugs that could have been
caught from simple unit tests. From my experience, coding without
testing is 4x bad. Programmers can produce twice the code with
twice the bugs instead of 1x the code and 0.01x the bugs.

> If I can run the code, I expect that language
> issues must be solved.

This is not even true with static languages.

> I am very much suprised when I receive a no method
> error. Why do I have to run the statement just to see that object  
> does not
> have that method implemented.

Try unit testing for a while and you will see. After doing
   1) write code
   2) write test
   3) run test and see it succeed

you start to get paranoid that your tests aren't being run. :)
Seeing them fail, then succeed has a euphoric effect.

> I would like to deal with bugs that are caused
> by the misapprehension or misimplementation of the problem.

Unit tests help here a lot since you essentially have to state the  
problem
from the users perspective.

> I prefer a language that loudly shouts at with discriptive  
> information when
> I do something wrong instead of running but producing erroneous  
> results.

Dynamic languages typically don't shout. Ruby has much more decorum.

> Just because of this I have the habit of using zillions of  
> assertions in my
> code when I developed in other languages. I have not been able to  
> find an

Why are you willing to write assertions but not unit tests?


Jim Freeze