From: Timothy W. <tw...@oc...> - 2002-04-24 19:57:17
|
Sorry, I'm missing some of your context. Could you elaborate on what=20 sequence was factored out and what you mean by "support TestSetup=20 without duplication"? The fact is, control *does* exist within the suite, even if it only=20 means that every test within the suite will be executed in turn. =20 Perhaps you meant control in the sense of any *other* sort of option in=20= 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.=20 > A TestSuite isn't a TestSequence--control shouldn't exist within the=20= > suite at all, it should be the responsibility of the GUI. > =A0 > Kent > > -----Original Message----- > From: jun...@li... [mailto:junit-devel- > ad...@li...]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=20 > 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=20 > argument > TestResult.run wraps the test in yet another object, Protectable, = which=20 > simply wraps TestCase.runBare in an interface function. It's not clear=20= > to me the purpose of this step, since Protectable.protect can throw = the=20 > same as TestCase.runBare. > > It doesn't look to me like any of this is useful to a derived class.=20= > However, it *would* be useful to have access to the test results, = which=20 > are not easy to get to in this implementation. Here's an idea that=20 > might facilitate access and control of test cases and suites: > > TestStep - supports run, add/removeListener, getError/Failure,=20 > stopOnError/Failure (see below) > TestSequence - extend TestStep to encapsulate several steps (aka=20 > TestSuite); supports dynamic stopOnError/Failure so you can run all=20 > tests or stop at the first failure. the sequence automatically listens=20= > to its sub-steps, and forwards their events to listeners. > TestEvent - start, in-progress, stop, error, failure - so any listener=20= > can determine the test state. > > For a concrete example of this pattern, see=20 > http://abbot.sourceforge.net/api/junit/extensions/awt/script/Step.html=20= > (also StepSequence) > |