I don't see the harm in having separate annotations for the different
things that could be injected rather than having what will amount to a
single injected struct...
On May 20, 2010, at 11:31 AM, 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?
>
> 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
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
