On Jan 23, 2007, at 21:05, David Chelimsky wrote:
> On 1/23/07, Eric Hodel <drbrain / segment7.net> wrote:
>> On Jan 23, 2007, at 16:26, James Edward Gray II wrote:
>> > On Jan 23, 2007, at 6:10 PM, Joe Van Dyk wrote:
>> >> What's wrong with zentest, specifically?
>> >
>> > You will probably understand better by watching the movie, but
>> > zentest encourages you to make a test case for each class and a
>> > test method for each method.
>>
>> Which will match up 1:1 if you factor your code well.
>
> I realize that you might have been put on the defensive here,

I don't really care if people use zentest or autotest or unit_diff or  
Test::Rails or not, but I will say that you're missing out if you're  
not testing.

> but the suggestion that 1:1 is the only natural conclusion of well  
> factored
> code denies a world of experience.

I'm going to cut and ignore some of your points to respond to this,  
which seems to be the core of your message.  I think the parts I've  
ignored are tangent to the central issue.

(If you want to see how I handle testing specific cases you can go  
through tests in my various projects.  You'll see I don't really do  
1:1 testing, and some are barely tested at all!)

>> > zentest encourages you to make a test case for each class and a
>> > test method for each method.
>>
>> > BDD teaches that these decisions are pretty arbitrary.
>>
>> I don't use BDD because I already have my tests broken up by units of
>> behavior.  I call them methods.
>>
>> BDD presents a method of thinking about test design to help you focus
>> on better object design and object modeling.  Unit testing doesn't
>> have this method of thinking built-in, you have to discover it.
>
> I'm not sure I understand the distinction you're trying to make here.
> TDD/BDD is all about discovery.

I added back some context.  I believe James' assertion was that  
ZenTest's approach was different from BDD's approach.  They are the  
same, but test/unit has less philosophy standing behind it, and less  
guidance about how things should be done.

Generally, implementing a BDD specification would end up as a method  
for me.  This happens because I use feedback from both the tests and  
the implementations to improve my code.

>> > This class and method organization is also encourages you to use  
>> so-
>> > so names for your tests at best.  If you have a Calendar class and
>> > a TestCalendar, that's pretty much saying the same thing twice (a
>> > violation of DRY) and it doesn't tell you much.  BDD encourages you
>> > to actually express what you are testing with your naming.  This
>> > really helps you focus on the goal of the process and is much less
>> > arbitrary.
>>
>> Mapping tests to classes 1:1 is a sign of proper design.
>
> Again, I disagree. 1:1 mapping is a sign that you are good at
> following policy, nothing more. If I write a giant class that has 50
> methods with a single test case with 50 corresponding test methods
> I've met 1:1, but I still probably have a shitty design.

Following policy is not listening to your code, which I touched on in  
the context below (and hopefully enough above).  I listen to my code,  
and 50 methods tells me its screaming in pain.

> If I have some other, looser ratio of tests/classes and every time I
> need to add features to my app it takes 10 times what I expect it to,
> I probably have a shitty design.
>
> On the flip side, if I have a design that is easy for me or any of my
> colleagues to extend as business requirements change, then I have a
> good design. For that to happen there is probably good test coverage,
> but I really don't think that 1:1 mapping has much to do with it.
>
> But that's just me.

Following rules sucks, and honestly I really don't do 1:1 the way you  
present it (I probably misrepresented myself due to inexact  
expression).  It just falls out that way for me because of my style  
and the way I listen to my code and my tests.

I don't want to say, "YOU MUST TEST 1:1!" since that misses out on  
half of the information you get from testing.  I want to say  
something like, "write your tests, listen to your code, listen to  
your tests, then refactor and make it simpler.  Then do it again and  
again and again.  Once you're in the habit you'll just have to the  
first four.", but even that doesn't get what I want to convey across.

Oh, and any time your code does something unexpected, write a test.

I still feel that what you test (or specify) should translate very  
closely to what you implement, unit to unit (or behavior to  
behavior).  For me this smells good, feels good, flows well, and is a  
pleasure to work with.  It took me a long time (at least three years)  
to figure out what I was supposed to be doing, and I've still got  
years to go to get it right.  Most of it was from doing unpleasant  
things and getting stuck in crappy code.  (Basically, the easier it  
is, the more I think I'm doing something right.)

We have these marvelous tools (be it test/unit or BDD-style) and it  
takes a while to realize we're probably using only half of what it  
can tell us (the tests all pass, done!) and ignoring the half that  
can make code beautiful.  Not because of ignorance, but because the  
information is conveyed in a way that's unusual at first.

It took effort for me to look at code and say "it would be so much  
cleaner if...", "it would be so much simpler if...", "I can remove  
this whole class by...".

Now I can look at something and say "oh, eww, I could just do this  
and this falls off, then that falls off then ...".

I don't know how to teach people to see it, but its there, if you  
look and listen.

>> Your
>> implementation's names should reflect the behavior implemented
>> within.  If you have to give different names to your tests and your
>> implementation you've probably named your implementation poorly.
>> Instead you should refactor your implementation so that it can be
>> named well.
>>
>> Read the tutorial on the rspec site:
>>
>> http://rspec.rubyforge.org/tutorials/index.html
>>
>> The specifications match up with the implementation very well, so the
>> Stack is probably well-designed
>> If they didn't, that's a good sign
>> of code smell.
>>
>> (You get the same code smell out of unit testing, it just smells a
>> little different.)

-- 
Eric Hodel - drbrain / segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!