Re: sequence. The catch block for AssertionFailedError. It was originally in TestCase. It moved to TestResult when we implemented TestSetup to avoid duplication.
 
Re: control. TestResult.stop() is a bad idea. The GUI should control running the next test. A TestIterator would be nice, walking over a test suite one test case at a time. It's complicated by the existence of TestDecorator, however, and by other implementors of Test.
 
Kent
-----Original Message-----
From: twall@oculustech.com [mailto:twall@oculustech.com]
Sent: Wednesday, April 24, 2002 12:57 PM
To: Kent Beck
Cc: JUnit Developer List
Subject: Re: [Junit-devel] structure of test invocation

Sorry, I'm missing some of your context. Could you elaborate on what sequence was factored out and what you mean by "support TestSetup without duplication"?

The fact is, control *does* exist within the suite, even if it only means that every test within the suite will be executed in turn. Perhaps you meant control in the sense of any *other* sort of option in the execution pattern?

Thanks
T.

On Wednesday, April 24, 2002, at 03:02 PM, Kent Beck wrote:

The sequence was factored out to support TestSetup without duplication. A TestSuite isn't a TestSequence--control shouldn't exist within the suite at all, it should be the responsibility of the GUI.
 
Kent

-----Original Message-----
From: junit-devel-admin@lists.sourceforge.net [mailto:junit-devel-admin@lists.sourceforge.net]On Behalf Of Timothy Wall
Sent: Wednesday, April 24, 2002 10:27 AM
To: JUnit Developer List
Subject: [Junit-devel] structure of test invocation

Anyone who's looked at the TestCase invocation has probably been a little puzzled by the flip flop of control.

TestCase creates a TestResult
TestCase invokes its own "run" with the result as an argument
TestCase.run(TestResult) invokes TestResult.run with itself as an argument
TestResult.run wraps the test in yet another object, Protectable, which simply wraps TestCase.runBare in an interface function. It's not clear to me the purpose of this step, since Protectable.protect can throw the same as TestCase.runBare.

It doesn't look to me like any of this is useful to a derived class. However, it *would* be useful to have access to the test results, which are not easy to get to in this implementation. Here's an idea that might facilitate access and control of test cases and suites:

TestStep - supports run, add/removeListener, getError/Failure, stopOnError/Failure (see below)
TestSequence - extend TestStep to encapsulate several steps (aka TestSuite); supports dynamic stopOnError/Failure so you can run all tests or stop at the first failure. the sequence automatically listens to its sub-steps, and forwards their events to listeners.
TestEvent - start, in-progress, stop, error, failure - so any listener can determine the test state.

For a concrete example of this pattern, see http://abbot.sourceforge.net/api/junit/extensions/awt/script/Step.html (also StepSequence)