To me the content of the L2s object database is akin to static data in a regular junit class. That means that each test class gets its own L2, but that L2 is shared by all the instances of that class, and hence all the test methods. Does that make sense?
On May 20, 2010, at 11:46 AM, Alex Snaps wrote: > 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 _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
