[John D. Mitchell <johnm-sf@no...>]

>>>>> "Bill" == Bill Venners <bv@...> writes:
[...]

> 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();

I'm more or less agnostic on this point.  I have general preference for
symmetry but I don't have anything in mind that would require that.


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

Interesting.


[...]

>> Personally, I don't like the idea of being able to mutate the context
>> from 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 agree.  I just wanted to make sure that it was clear that the primary
focus is on each suite.

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

While I agree that somebody would want to create a DB connection and reuse
it for a complete run, I must say that that's a bad idea.  Perhaps I'm just
being particularly persnickety but I think it's very bad to have any
potential interaction such as driver caching, bugs, etc.; potential
residual DB-side caching, etc.; etc.

Have fun,
	John