On Tue 07 Aug 2012 11:08:27 AM CDT, Hardy Ferentschik wrote: > > 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.
Yep, this is a great point about re-writing. If you are testing something, direct tests/assertions are always the best route. I think its ok to extend the BaseUnitTestCase. But totally agree that extending BaseCoreFunctionalTestCase does not make any sense for tests specifically testing Metadata building (heck that is really the case for tests that test building a Configuration too). > For this reason I envision also a whole set of > different base classes each addressing different testing needs. Well?!? Where are they? :D J/K, but yeah, maybe we do need some new tests specific to building a ServiceRegistry as a fixture, building a MetadataSources as a fixture, etc... >> 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. -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
