Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write some unit tests for composite cycles (Pick some cases! Have fun!) #86

Closed
ghost opened this issue Feb 27, 2013 · 1 comment
Closed
Assignees

Comments

@ghost
Copy link

ghost commented Feb 27, 2013

There's currently a test to handle instances where duplicate composite types are understood correctly... testUnderstandingOfBasicRefs

Whenever we find a cycle or a duplicated object, we'll ideally have a set of ID's and REF's. An "ID" identifies an isntance of a composite with all of the other interpretations inside. A "REF" is a reference to an object with an "ID"

Suppose I have these three classes:

class A
{
@simpl_composite 
public B myB; 

@simpl_scalar
public Double aDouble; 
}

class B
{ 
@simpl_composite
public C myC;

@simpl_scalar
public Integer bID;
}

class C
{ 
@simpl_composite
public B myB;

@simpl_composite
public A myA; 

@simpl_scalar
public String cName;
}

There's a lot of gnarly and tricky ways where I could have cycles in some instances of these classes. An instance of A could have an instance of B that has an instance of C that refers to both the instance of B and the instance of A... for example. (You could implement that case, actually! That'd be a good start.)

Another thing (to borrow the notation I used in #74):
We don't necessarily make ordering guarantees about wether or not we see the ID of a composite first, or second... etc...

So you could write a few different tests that shift the ID/s and Refs around...
So, for example, this is one good test case for a non-graph reference:

tree_class
leftNode: my_scalars (REF = 1) {}
rightNode: my_scalars (ID = 1) {
aDouble = "1.3" (DoubleType)
aInteger = "13" (IntegerType) 
aField = "string" (StringType)
}

I expect the same value at the end of the understanding process if the interpretations look like this:

tree_class
rightNode: my_scalars (REF = 1) {}
leftNode: my_scalars (ID = 1) {
aDouble = "1.3" (DoubleType)
aInteger = "13" (IntegerType) 
aField = "string" (StringType)
}

And this test case is a bit less helpful, but at least illustrates that there's many different ways to skin a cat:

tree_class
leftNode: my_scalars (ID = 1) {
aField = "string" (StringType)
aDouble = "1.3" (DoubleType)
aInteger = "13" (IntegerType) 
}

rightNode: my_scalars (REF = 1) {}

So basically: Write some cycle tests!
Send me the link, etc whenever you make the commit and I'll review.

@AndrewKoons
Copy link
Contributor

320ce62

@AndrewKoons AndrewKoons reopened this Mar 21, 2013
@ghost ghost closed this as completed Mar 21, 2013
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant