[hibernate-dev] OGM test refactoring

Wed Apr 15 09:53:52 EDT 2015

On 15/04/15 13:54, Gunnar Morling wrote:
> How many tests are affected by this problem?

hmm, good question. At present most of the association tests and a 
handful of assorted others that happen to use associations are blowing 
up because I haven't finished the association support.  I'm working 
through them gradually, resolving the legit failures and excluding the 
one that can't be expected to ever work.  My feeling so far is that it 
will affect maybe 5-10 test classes, which for refacoring purposes is a 
more important count than number of test methods.

> If not too many, it might be feasible to split those test methods into
> several test classes (each only referencing the entities it actually
> needs) which you then can mark individually with @SkipByGridDialect as
> needed.

umm, the point is that @SkipByGridDialect doesn't work, or I could just 
put it on existing methods. However that's a moot point, since if it's 
refactored to a separate class I can exclude it by class name in the 
pom.  Not sure I like the ongoing cognitive load of having two different 
strategies for test exclusions, but it's certainly less engineering 
effort than adding support for method level POJO usage declarations.

>
> I am no big of copying/pasting tests to the backend, we generally aim
> for having as many tests in the TCK as possible. Only tests for
> store-specific features or the persistent format should be in the
> backends whenever possible. Sub-classing might work, though I find it
> not as nice to work with, as it requires you to look/edit at two places
> when working with a given test (we have some tests which use that
> pattern for MongoDB). I also would prefer to not change semantics of
> existing tests.
>
> I like the idea of a @TestEntities(Entity1.class, Entity2.class)
> annotation which allows to specify the required entity types per test
> class and/or method (probably cumulative, if given at both levels). This
> would be my preference if splitting up doesn't work.
>
> Can you name an example of a test affected by this?

Basket.java:  @OneToMany List<Product>  from ManyToOneTest

>
>
>
> 2015-04-15 13:41 GMT+02:00 Jonathan Halliday
> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>>:
>
>
>     In the course of developing the cassandra backend for OGM I've hit an
>     issue with some of the backendtck tests.
>
>     These tests are in core and reused by each backend. It's possible to
>     exclude tests at class or method level per backend, which prevents
>     irrelevant tests from running for a given backend. So far, so good.
>
>     The problem I'm seeing stems from the fact that even when a test is
>     excluded, the annotated POJOs it uses are still parsed and passed
>     through schema creation, since that occurs in a setup step before the
>     individual tests are iterated and (not) run.
>
>     There are certain POJOs that contains mappings cassandra can't support.
>     Even with the corresponding test disabled, when these are passed to the
>     schema creator it blows up, effectively preventing the other legitimate
>     tests in the same class from running.
>
>     In an ideal world I'd like a class/method level annotation listing the
>     required POJOs to replace the getAnnotatedClasses method, allowing POJOs
>     to be parsed or skipped in accordance with the corresponding annotation
>     on the same test method.
>
>     @RequiredPOJO(Foo.class)
>     @Test
>     @SkipByGridDialect(...)
>     public void testFoo()
>
>     Alternatively I can (I think) subclass the test class in the backend and
>     override the getAnnotatedClasses method to exclude the problem POJOs,
>     whilst leaving the @SkipByGridDialect on the shared parent for clarity.
>        Or simply copy and paste the whole thing and nuke the offending
>     POJOs/methods in my backend's copy.
>
>     On a related note, many of the offending tests could be altered in such
>     a way that the resulting schema is acceptable to cassandra, which would
>     largely sidestep the issue but alter the test semantics. In many
>     instances I suspect the semantic in question is one that's not critical
>     to the test's intent, but I may be wrong.
>
>     Essentially cassandra uses what a relational db would call 'index
>     organized tables', i.e. the on-disk layout of data is a function of the
>     table's key. As a result, it's not possible to declare tables without a
>     primary key. Such mappings result from collections with bag semantics,
>     such as @OneToMany List<Object>, since the list may have dups. Removing
>     the bag semantics such as by adding an index column, avoids this issue.
>     But then you're testing something different...
>
>
>     Any preference on the approach to changing the test suite?
>
>     Jonathan.
>
>     --
>     Registered in England and Wales under Company Registration No.
>     03798903 <tel:03798903>
>     Directors: Michael Cunningham (USA), Matt Parson
>     (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)