[hibernate-dev] Unit test failures using the new metamodel
Hardy Ferentschik
hardy at hibernate.org
Tue Aug 7 12:08:27 EDT 2012
On 7 Aug 2012, at 15:02, Steve Ebersole <steve at 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
More information about the hibernate-dev
mailing list