Re: [Perlunit-users] Using @TESTS for changing tests execution order

[Dmitry D. <dd...@ic...>]

Matthew Astley wrote:
> On Sat, Oct 04, 2003 at 10:06:19AM +0400, Dmitry Diskin wrote:
> 
> 
>>I read from TestCase.pm POD that one can populate @TESTS array in
>>order to specify the desired order of tests execution:
> 
> 
> Ah, I started at the bottom of my inbox and worked back...  why does
> it matter what order the tests run?  The xUnit idea is that each test
> (and its associated setup/teardown) should stand alone.

Suppose that one test is for database INSERT statement, and the other -- 
for SELECT, and that last -- for DELETE. That way I need to maintain the 
order of tests execution. Of course, I can put all operations into one 
test instead.


> 
> 
>>### quote begin
>>
>>If you need to specify the test order, you can do one of the
>>following:
>>
>>=over 4
>>
>>=item * Set @TESTS
>>
>>  our @TESTS = qw(my_test my_test_2);
>>
>>This is the simplest, and recommended way.
>>
>>### quote end
> 
> 
>>But the above does not work for me. I can include only desired tests
>>using @TESTS, but they are listed and executed in a random order,
> 
> 
> Hmm, that comment seems to be out of date.  @TESTS is piled into a
> hash, then the keys are listed as you said.
> 

Aha.. That is the clue! Thanks. I should study sources myself :)

>>I decided to override list_tests method like this:
>>
>>sub list_tests {
>>    my $self = shift;
>>    return sort $self->SUPER::list_tests(@_);
>>}
> 
> 
> That would do it, yes.  Did you see in Test/Unit/TestCase.pm,
> 
>   # Returns a list of the tests run by this class and its superclasses.
>   # DO NOT OVERRIDE THIS UNLESS YOU KNOW WHAT YOU ARE DOING!
>   sub list_tests {
>       ...
> 
> Maybe that comment could be more helpful...  8-/
> 
> 
>>It works as expected. What do you think? Am I missing something?
> 
> 
> Well it could be that you are missing something.  If you try to avoid
> using side effects from each test, then the order should not matter.
> 
> I suppose one day the tests may be run in parallel.  That would be
> neat, and it would also be incompatible with explicit test ordering.
> 

Hmm.. Never thought about parallel execution.. Indeed it may be a godd idea.

-- 
Dmitry.