[hibernate-dev] Unit test failures using the new metamodel

[Steve Ebersole]

On Tue 07 Aug 2012 11:24:34 AM CDT, Steve Ebersole wrote:

>>>  What John and I discussed when we worked out the
>>> @FailureExpectedWithNewMetamodel was to possibly "store" start up
>>> failures (exceptions) and use them for each grouped test method.  I
>>> think that is not unreasonable, even long term, so I will work on
>>> that change after 4.1.6.
>>
>> Where possible I would prefer better written test, but given st we
>> have so many legacy test it probably makes sense to take care of this.
>
> Yep that was my thought process as well.  This is pretty clearly a
> case of badly written tests or tests being used in ways they were not
> intended.  But what I suggest should be a pretty small change and not
> bad in and off itself.  And would certainly help in this situation.
> And we have to keep in mind that once this process of building a
> SessionFactory from Metadata moves from transitory, those tests will
> again be correct (even as they are now!) and useful.  Its not the
> tests themselves that are "bad" (at least a lot of them we discuss
> lately). We just happen to be using them in a non-anticipated and
> arguably non-correct way as we make this transition.
>
> I think we just need to keep in mind that the intent here is really to
> flush out what is still lacking in the metamodel code.  That was the
> up front discussion and the only way it makes sense to use these tests
> as we are right now during this transition.

Ok, this may not be possible after all.  At least, it may not be 
possible in conjunction with "failure expected".  The problem lies in 
the fact of how JUnit layers callbacks (and how we tie into that 
process) into the execution of a test.  It uses a contract called 
Statement to represent something to be executed.  At the very base you 
have a Statement that performs the test method.  Around that you have 
another Statement that applies @Before callbacks.  Around that you have 
yet another Statement that applies @After callbacks,  Etc.  It is 
essentially "around advice", each successive level delegating to the 
next after applying its special advice.

The problem is that our Statement for "failure expected" handling is 
"inside" the Statement for callbacks.

--
steve at hibernate.org
http://hibernate.org