Thanks Graeme.
I've come to the same conclusion. More generally, I think we can add a
test entity that uses both `target` and `targetId` parameters from
TargetableTestComponent with a `scope` parameter (of type
org.apache.brooklyn.camp.brooklyn.spi.dsl.methods.DslComponent.Scope).
The entity to be tested is the combination of `targetId` and `scope`
resolved against `target`.
If we call this a "relative" test case, I would then structure my test
case along the lines of this pseudocode:
loopOverGroupMembers:
spec:
relative:
# target entity (= group member) set by loopOverGroupMembers
targetId: foo
scope: child
I'm mid-way through testing this idea, will report back if it proves useful.
Sam
On 17/06/2016 12:50, Graeme Miller wrote:
I think what we are missing is a LoopOverChildrenTestCase. It would be very
similar to LoopOverGroupMembersTestCase and can probably share some code. A
combination of LoopOverGroupMembersTestCase followed by
LoopOverChildrenTestCase should allow you to test the structure you
mentioned.
Regards,
Graeme
On 17 June 2016 at 11:24, Sam Corbett <[email protected]> wrote:
Hi,
I want to use Brooklyn's test entities to test an app with the following
structure:
cluster:
- member 1
- child 1
- member 2
- child 2
The things I want to test are on the child entities. Every child has the
same CAMP id.
LoopOverGroupMembersTestCase gets me the members, but can I get from them
to the children? Having experimented lots I currently think the answer is
no.
I'm wondering whether there's a case for a `RelativeEntityTestCase` class,
that resolves its target relative to its parent entity. (I had assumed that
that was what LOGMTC would do, but in fact it overwrites any test spec
target with the group member.)
Can anyone help?
Thanks,
Sam.
