>> Well, I was hesitant on the setup and teardown for suites, only
>> it was easy to do in a subclass, and I wasn't convinced it was
> It's at least as important as the general context blob that you're
> For example, taking the database example a bit deeper... For me, each
> individual suite is a coherent set of tests that rely upon a specific
> database setup (including content). The suite-level setup & teardown
> for a very clear and clean approach to managing this.
> In the project that I first brought this up, we used the setup and
> to create our databases from scratch, insert triggers and stored
> procedures, insert data, and then clean all of that junk up for the
I see. Well, if we add a pair of setUpSuite and tearDownSuite methods,
can we just pass the context to setUpSuite and leave it at that? I.e.,
we wouldn't need a setContext and getContext. To get ahold of the
context, you override setUpSuite. Would we need to pass it to
tearDownSuite? Can you think of an instance where it would be needed in
tearDownSuite? I suppose if you really wanted something around at
tearDownSuite time, you could store it when it comes into setUpSuite.
So the signatures would be:
public void setUpSuite(Map context);
public void tearDownSuite();
The default version of setUpSuite would store the passed in Map in a
private instance variable, and then use that to pass to subsuites when
it invokes execute on them. In that case, if you override setUpSuite,
you need to call super.setUpSuite() if you want that passing down
behavior to happen.
>> I just checked in all the changes I made today. I've tested it a bit.
>> Check out the latest and run the doc target and you can see what I
>> to the public interface. I added a setContext and getContext. I call
>> setContext before calling execute. I'm concerned about ordering. I
>> implement a way to specify user-defined properties on the command
>> line. And I don't call setContext before rerunning tests or suites
>> via the GUI by pressing the rerun button), just when the suites in a
>> recipe are executed. So there are lots of things to think about. If
>> see this as a setup thing on the suite, then describe that. I have
>> seeing it more as something that is done once for the entire run, and
>> then needs somehow to be passed to all the suites. That's why Frank
>> I were originally thinking of sticking this in the Reporter, because
>> Reporter goes everywhere already.
> Personally, I don't like the idea of being able to mutate the context
> suite to suite. Suites are the "nautral" unit of granularity in the
> SuiteRunner world.
There is one larger unit of granularity, and that's the "run" of a
suite of tests. I figure some people will want to set up some things at
the run level, not the level of each individual suite. Things like a
database connection. I am imagining people wanting to mutate the
context only at the beginning of a run, taking information expressed in
string properties, and turning them into live database and socket
connections, which becomes the new context used by all suites. To
accomplish this with setUpSuite and tearDownSuite, what they would do
is their main Suite would override setUpSuite. That implementation
would grab the string database name out of the context map, open a
connection to the database, create a new map and put the database
connection into it, then call super.setUpSuite(newMap). Since they're
passing the new map that contains the live database connection to the
superclass, that's the map that will be sent around to everything, and
the database need only be connected to once. That will save a lot of
time. The individual Suites can use setUpSuite and tearDownSuite to
clean the database and add new data in there, but they wouldn't need to
open a connection each time.
So while it is possible for one suite to communicate to another as the
test goes on by placing things in the context map, and somewhere
someone will probably find a reason to do that, the main way I forsee
that happening is at the beginning of a run.
> I do think the context is quite useful (from the properties/recipe
> file and
> the command-line :-) for precisely the sorts of genericizing
> like URLs, ports, DB (driver) names, etc. However, for truly dynamic
> things such as a DB connection, they should be managed via the
> setup and teardown.
OK. You've sold me. I see my job as benevolent dictator of the public
API to say no, no, no, no, well, no, no, hmm, no, well maybe, no, I
see, OK. Right, great idea. I also noticed yesterday that someone had
made an enhancement request to JUnit about a setup and teardown methods
at the level of the entire test case, so that's two people asking for
it. But mainly, I think this is the most sensible way to pass the
context in of all the approaches I've considered so far. So I'll make
those changes after my late morning jog, which I'm leaving on right
now, then check them in so you guys can take a look.
Thanks for being persistent.
Artima Software, Inc.