Re: Testing with concurrent sessions

Markus Wanner  wrote:
Kevin Grittner wrote:
> I differentiate tests and test suites. Tests mainly have a run
> method, while test suites have setUp and tearDown ones.
I hadn't caught on to that distinction yet.  That should help.
>> "uses" means that the referenced task has complimentary setUp and
>> tearDown methods, and the dependent task may only run after a
>> successful invocation of the referenced task's setUp method, and
>> the referenced task will wait for completion of all dependent
>> tasks before invoking tearDown.
>
> Absolutely correct (may I just copy that para for documentation)?
> ;-)
Use any of my language that you like, but I'm not generally known for
my word-smithing ability, so use at your own risk.  ;-)
> Two additional things: tests and test suites may have requirements
> (in the form of interfaces). The used test suites are passed to the
> dependent task and it may call the referenced tasks's methods, for
> example to get the database directory or to run a certain SQL
> command.
Makes sense.
> Second, if the referenced task fails, any running dependent task is
> getting aborted as well. That might be obvious, though.
I figured that, although it's good to have it confirmed.
>> "depends" means that the tearDown method of the referenced task
>> doesn't undo the work of its setUp, at least for purposes of the
>> dependent task. The dependent task can only start after successful
>> completion of the referenced class's work (*just* setUp, or all
>> the way to tearDown?), but the referenced task doesn't need to
>> wait for the dependent task.
>
> Hm.. no, not quite. The fact that not all suites clean up after
> them has nothing to do with how they are referenced ("uses" or
> "depends"). So far, it's entirely up to the test suite. I dislike
> that, but it works.  (I've been thinking about some separate
> resource allocation handling and what not, but..)
>
> The only difference between "depends" and "uses" is the
> requirements fulfilling. "uses" does that, while "depends" only
> adds the timing and functional dependencies, but doesn't pass the
> referenced task as an argument to the dependent task.
OK, that accounts for most of the differences between what they
sounded like to me and what I saw in the code.  That's workable, now
that I understand it.
>> "onlyAfter" means that the dependent task must wait for completion
>> of the referenced task, but doesn't care whether or not the
>> referenced class completed successfully.
>
> That's how I think it *should* be. ATM "onlyAfter" requires
> successful completion of the dependent task.
That accounts for the rest of the differences.
> I'd like to change that to support "onlyAfter",
> "onlyAfterSuccessOf" and "onlyAfterFailureOf". Plus "onlyBefore"
> for convenience.
onlyAfterSuccessOf would be the same as depends with an empty
tearDown method?  So it would effectively be syntactic sugar, for
convenience?
An onlyBefore reference from a to b would be semantically identical
to an onlyAfter reference from b to a?  If so, that one seems to me
like it would muddy the waters more than it would help.
> Thank you for thinking through all of this. I'm sure you understand
> now, why it's not a version 0.1, yet :-)
Thank you for putting it together!  I was afraid I was going to have
to go off-task on serializable implementation to write something so I
could test it.  I'm more than happy to help stabilize your tool
instead!
-Kevin