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?
On 20 May 2010, at 17:20, Chris Dennis wrote:
> So this would be the route in for direct toolkit users? In express we
> would instantiate a StandaloneClusteringProvider connected to the
> server that the test framework started, in standalone we would
> instantiate a dummy, and in custom we would just do
> Clustering.provider() and get the globally (or classloader) scoped
> instance?
>
> What if I've written a toolkit/express product and my product has its
> own bootstrapping class much like Express Ehcache. Will I be able to
> have the URL of the server injected instead so that I can feed that to
> my application in whatever way it normally handles it?
>
> Chris
>
> On May 20, 2010, at 11:02 AM, Geert Bevin wrote:
>
>> Sounds all good to me!
>>
>> On 20 May 2010, at 16:28, Alex Snaps wrote:
>>
>>> Since we have more targeted platforms than DSO now, we've decided
>>> to put a new test framework in place that would enable developers
>>> to run tests as easily as possible in all 3 environments: Custom,
>>> Express and "standalone" (i.e. no clustering).
>>> The way I've started this is that tests are simple junit tests that
>>> need to be annotated with @TerracottaTest like this:
>>>
>>> @RunWith(TerracottaRunner.class) // Still trying to get rid of this
>>> guy here!
>>> @TerracottaTest
>>> public class usefulTest {
>>>
>>> @Test
>>> public void testSomethingUseful() {
>>> }
>>>
>>> }
>>>
>>> By default, this would result in the test being run in all 3
>>> environments. One could influence this by specifying the targeted
>>> environments as:
>>> @TerracottaTest({TargetEnvironment.EXPRESS,
>>> TargetEnvironment.CUSTOM})
>>>
>>> The annotation currently also takes an additional parameter,
>>> participants:int, which defaults to 2
>>> Now in order to orchestrate these participants, one would generally
>>> rely on a j.u.c.CyclicBarrier... which would be obtained by a
>>> ClusteringProvider.getBarrier("myBarrier", 2);
>>> In order to get to the appropriate ClusteringProvider, I was
>>> thinking about injecting it in the test through the mean of some
>>> annotated field. Should the test be in "standalone" (i.e. 2 threads
>>> running the "classpath isolated" test), I'd inject some
>>> DummyPersistenceProvider.
>>>
>>> This makes the most sense to me right now, wdyt?
>>> Thanks,
>>> Alex
>>>
>>> _______________________________________________
>>> tc-dev mailing list
>>> tc-dev@lists.terracotta.org
>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>
>> --
>> 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
