Re: Testing with concurrent sessions

Hi,

Kevin Grittner wrote:
> I'm a little unclear about the differences between "uses",
> "depends", and "onlyAfter". Here's what they *sound* like they
> mean, to me; although I don't think the code isn't entirely
> consistent with this interpretation.

Wow, you are way ahead of me. I intended to write some documentation
about that, but...

I differentiate tests and test suites. Tests mainly have a run method,
while test suites have setUp and tearDown ones.

> "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)? ;-)

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.

Second, if the referenced task fails, any running dependent task is
getting aborted as well. That might be obvious, though.

> "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.

> "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.

I'd like to change that to support "onlyAfter", "onlyAfterSuccessOf" and
"onlyAfterFailureOf". Plus "onlyBefore" for convenience.

This is all work in progress and I'm open to suggestions and requests.

Thank you for thinking through all of this. I'm sure you understand now,
why it's not a version 0.1, yet :-)

Regards

Markus