From: zohar <zohr@...>
Date: 2002-03-17T15:32:30+09:00
Subject: Re: testunit - setup -> set_up ?

I want to unsubscribe from ruby talk. What is the way?
my email address is zohr@im.eth.net 
----- Original Message ----- 
From: "Nathaniel Talbott" <nathaniel@talbott.ws>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Saturday, March 16, 2002 6:56 AM
Subject: RE: testunit - setup -> set_up ?


> dave@thomases.com [mailto:dave@thomases.com] wrote:
> 
> > "Nathaniel Talbott" <nathaniel@talbott.ws> writes:
> > 
> > > Here's an idea (if I can make it work): what if the implementation
> of 
> > > #set_up (or whatever it's called) in TestCase takes in a block like 
> > > you're proposing? Those who want to do things the new, cool way can 
> > > use it as proposed above, and those who would rather stick with the 
> > > old xUnit nomenclature (or are porting older code) can still use old
> 
> > > faithful.
> > 
> > Yes! I like that.
> 
> Good. I'll see about adding it.
> 
> 
> > Now, on to the overall setup issue.
> >
> > One of my big gripes with JUnit is the fact it's such a pita 
> > to do per-suite initialization. If I want a database 
> > connection for all my tests, I either have to write a 
> > singleton (with the attendant leak) or dig out a template to 
> > work out how to do the stupid decorator trick. All I really 
> > want to say is "before running any of the tests in this 
> > class, do X, and after finishing the last, do Y". As such, I 
> > think the overall setup and overall teardown are really just 
> > attributes of the test case, and so logically belong in there 
> > with the tests. It also seems to make good sense from a 
> > packaging point of view:
> 
> Point taken. I wonder if the decorator has to be so difficult and hard
> to remember in Ruby, but since I can't think of a way to make it
> otherwise, this seems like a great alternative. Perhaps I'll just create
> a decorator automagically when this strategy is used, leaving you the
> tools and the option to create one yourself if you feel like it.
> 
> I favor having a decorator readily available because sometimes you want
> some resource set up before a whole set of test cases, and torn down
> only after all of those test cases have run. This would seem to be YAGNI
> except I was on a project where we did exactly that, due to the high
> cost of setting up our persistence tests coupled with a desire to break
> them out in to multiple test cases.
> 
> Perhaps doing what you propose will bring insight in to making the
> decorator simpler; that would be very cool.
> 
> 
> >   require 'test/unit'
> > 
> >   class MyTests < Test::Case
> > 
> >      before_all_tests do
> >        @conn = DB.get_connection
> >      end
> > 
> >      before_each_test do
> >        @conn.reset
> >      end
> > 
> >      after_each_test do
> >        @conn.rollback
> >      end
> > 
> >      def test_one
> >        stmt = @conn.prepare(...)
> >        ...
> >      end
> > 
> >      def test_two
> >        stmt = @conn.select(...)
> >        ...
> >      end
> > 
> >      after_all_tests do
> >        @conn.close
> >      end
> >   end
> > 
> > 
> > For me, that's all I'd want to specify for a set of tests. It 
> > seems easy to remember, and there's no extra crud to insert. 
> > The above file would be literally all you type to get some 
> > tests up and running.
> 
> I like having them specified at the class level. That was much of what
> smelled for me with the last proposal. A question, though: what's the
> best way for test instances to access class instance variables? I didn't
> think direct access as you do above would work.
> 
> Also, a clarification: are #before_each_test and #after_each_test only
> for doing things to the overall resources? Or are you proposing them as
> alternatives to the instance level set up method? If the former, cool;
> if the latter, I think it would cause implementation grief.
> 
> 
> > However, I'm sure I'm missing a heap of implementation problems.
> 
> Actually, not having done any of it yet, it appears to be a SMOP. But
> appearances can be deceiving. Even if it is tough, these are great
> ideas, and I think they belong somewhere. The right form will emerge in
> time.
> 
> Thanks,
> 
> 
> Nathaniel
> 
> <:((><
> + - -
> | RoleModel Software, Inc.
> | EQUIP VI
>