Well I can only speak from core and why we decided to make the split there.
hibernate-testing is all the classes which are useful for writing tests. Stuff like our test base classes and our trivial JTA TM impl. Specifically stuff that is useful for writing *functional* tests. hibernate-testsuite is the actual set of functional tests relating to hibernate-core. Couple of thoughts played into this and of course the fact that we are using maven came into play. First I wanted to distinguish between unit tests and functional tests. Ideally I'd really like CI to be essentially a 2 step process: 1) build artifacts and run *unit* tests 2) run "matrix" against functional tests Second I wanted to provide an artifact that allowed users an easy way to write tests for themselves both in their build process as well as part of bug reports. This has not been overly successful unfortunately. Many of the modules use it. Yes we could probably integrate both back into hibernate core as part of the test "source set" and have the modules depend on them via the testsuite artifact, but like I mentioned before on this thread that muddies the intent in my mind. Not to mention that it does not allow us the ability to run just the unit tests during build and the functional tests separately. Its one of the inflexibilities of Maven. I am not sure what the "right" answer is as each have serious drawbacks IMO. On 03/21/2010 06:20 PM, Sanne Grinovero wrote: > it's ok for me because of your "consistency with core" argument but I > have no clue about why this setup is useful. > (I like consistency, but had to hang this poster as a reminder in my > room: http://site.despair.com/images/dpage/consistency03.jpg) > > I'm still wondering what's the difference between: > hibernate-search-testing/ > hibernate-search-testsuite/ > > but have no doubts you know, let's see if I understand better after the > commit. > > Cheers, > Sanne > > > > 2010/3/20 Hardy Ferentschik<hibern...@ferentschik.de>: >> Ok, locally I have now the following structure >> >> pom.xml >> hibernate-search/ >> hibernate-search-archetype/ >> hibernate-search-testing/ >> hibernate-search-testsuite/ >> >> Tests are split out into hibernate-search-testsuite. We can still leave >> tests which don't extend >> SearchTestCase in hibernate-search, but there are not many ;-) >> >> This setup will allow to add a new infinispan module where the tests can use >> for example the >> SearchTestCase of hibernate-search-testing. We can also further split out >> the jms and jgroups >> clustering, but that's optional. >> >> The only way to keep the main tests in hibernate-search while still >> publishing a testing module >> would be some code duplication. >> >> I know there are still some reservations about this setup, so I thought I >> ask once more - >> commit or not commit? ;-) >> >> --Hardy >> >> >> >> >> On Wed, 17 Mar 2010 12:38:54 -0300, Hardy Ferentschik >> <hibern...@ferentschik.de> wrote: >> >>> Regarding the test util module (hibernate-search-testing). If we are >>> planning to split out >>> the different clustering parts (or for any other later module) we probably >>> want to >>> have all the test base classes in hibernate-search-testing as well (eg >>> SearchTestCase). >>> Obviously SearchTestCase depends heavily on core Search classes and an >>> additional >>> hibernate-search-util is not going to cut it. If we go the full monty we >>> would need >>> to break out all the test related utility/base classes into >>> hibernate-search-testing >>> and then move all tests into hibernate-search-testsuite. This is >>> effectively how Hibernate >>> Core is setup and it creates some consistency. I guess Steve had his >>> reasons after all to >>> go for the setup we have now ;-) >>> >>> I don't think we have to be too worried about people not running the >>> tests, because they >>> are in another module. The setup works for Core. Besides, I am a big >>> sucker for consistency >>> and I like the idea that Search would mirror the Core setup. Thoughts? >>> >>> Regarding the performance tests, I am not sure whether we need a separate >>> module for that. >>> The problem is now that these tests are excluded in the POM configuration. >>> I think we just >>> need a way to run them. Maybe a simple property 'mvn install >>> -Drun.performance.test=true' >>> We can then decide if the default should be true or false. >>> >>> --Hardy >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
