On 7 Aug 2012, at 15:02, Steve Ebersole <steve(a)hibernate.org> wrote:
> I'm not sure I understand what you mean? Do you mean that the
FailureExpected code is not intended to expect failures in @Before, @BeforeClass, and
@BeforeClassOnce callbacks?
That is exactly what I am saying. You have to step back and look at how tests are
structured. And this is not specific to Hibernate tests *in any way*. Test generally
have (1) a set-up phase (2) a test phase and (3) a tear-down phase. set-up and tear-down
are meant to deal with things called test *fixtures*.
Exactly what I was trying to say a :-) And this is exactly why I rewrote the tests we have
been discussed in this thread. Most of them were not even doing/asserting anything when
reaching the second phase. The "test" was just reaching the second phase. Really
the tests should have been written differently and not even extend our main base class for
tests.
With the old Configuration it was admittedly hard to write other type of tests, but here
is one of the strength of the new metamodel. The building of the configuration is now much
more open for testing. Many things don't need to be tested going all the way to the db
(also good performance wise!) For this reason I envision also a whole set of different
base classes each addressing different testing needs.
In thinking about this more, I think this situation makes some sense.
I was confused about why JUnit was just "eating" the failures. IIUC JUnit is
seeing failures in the set up phase and is simply ignoring the test.
+1
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.
--hardy