Right now, it would be one per test class... Though I thought I would want to change that. But I'm still looking into what options I have there (and let the user config that?): trying to reuse as much of junit as possible rather than rewriting it all. Would love to hear about your preferences though!
On 20 May 2010, at 17:42, Chris Dennis wrote: > How are you going to manage the L2s? One per test class, one per test > method, one for the whole test suite? I'm just wondering in terms of > the persistence of test objects breaking things... > > Chris > > On May 20, 2010, at 11:40 AM, Alex Snaps wrote: > >> That's how I started so far, yes. But that's still one thing I also >> wonder about. I thought that maybe, in some rare cases, one would >> want to specify the URL (rather than access to the one the f/w set >> up). But this goes with crappy consideration about the lifecycle of >> it all (like each test class specify a different desired URL), also >> should the f/w be able to connect "tests" to some random l2, not f/w >> managed? >> I've decided to ignore these 2 concerns for now. I think 99% of the >> use cases won't require anything like that, wdyt? >> >> On 20 May 2010, at 17:35, Geert Bevin wrote: >> >>> The URL should be optional, no? People that don't care which server >>> they're running with and just want to run functional system tests >>> in TC shouldn't need to specify the URL, right? >>> >>> On 20 May 2010, at 17:31, Alex Snaps wrote: >>> >>>> I indeed want the test fw to inject the proper provider depending >>>> on the current environment the test is being run in. >>>> As for injecting the URL, this will indeed also be required (say >>>> to configure your ehcache). >>>> I also expect the current Environment you're being executed in to >>>> become relevant (like loading different configs). >>>> Maybe I should rather inject some other TcTestContext that would >>>> also provide access to the ClusteringProvider? >>> >>> -- >>> Geert Bevin >>> Terracotta - http://www.terracotta.org >>> >>> _______________________________________________ >>> tc-dev mailing list >>> tc-dev@lists.terracotta.org >>> http://lists.terracotta.org/mailman/listinfo/tc-dev >> >> _______________________________________________ >> tc-dev mailing list >> tc-dev@lists.terracotta.org >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
