RE: testunit - setup -> set_up ?

[e-mail] [mailto:[e-mail]] wrote:

> "Nathaniel Talbott" <[e-mail]> 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