[hibernate-dev] ORM and database testing

Sanne Grinovero sanne at hibernate.org
Thu May 28 09:44:15 EDT 2015

I particularly like the idea of having H2 start/stop like any other db.

Regarding profiles, rather than running the build with a single
profile in "maven style", would it not be feasible to have one build
iterate on each configuration set?
For example:

 gradle test -PdbProfiles=mysql,h2,mssql

I'd expect that to do a single compilation phase, then loop on the
tests 3 times with different settings as needed. Not sure how easy it
would be to get unified reports out of there, but we want to consider
*the* build successful when it passes all profiles, rather than having
to monitor the output of multiple builds (and all related email spam).
In an ideal evolution then maybe we would also be able to mark some
tests which are database independent to not be repeated at all.


On 28 May 2015 at 14:33, Steve Ebersole <steve at hibernate.org> wrote:
> Now that CR1 is out one of my tasks is to start setting up the database
> specific jobs on CI.  Initially I will just work with MySQL and PostrgeSQL
> (and maybe HSQLDB).
> Part of this will be auditing how we do database testing (matrix plugin)
> and what does/doesn't work there.  I definitely like the idea of "database
> profiles".  Overall I am not sure that dynamically generating tasks
> specific to each database profile was a great idea.  It was predicated on
> the idea that I might want to run tests against all database profiles.  But
> that simply has not been the case in practice to date.  I have to look
> again at the complexity the actual matrix stuff adds.  If it is a lot of
> complexity I might just remove that part and have this be driven by a
> single build parameter (`gradle test -PdbProfile=mysql`, e.g.).
> I'd also like to look at specific hooks for the profiles in terms of
> pre-/post-events at the suite, class and test levels.  For example, we
> might have the H2 profile set up pre-post hooks for the suite to manage the
> database rather than each test building one itself.  This would have a lot
> of benefits.  Presumably it would help speed up the build some.  It would
> also work more closely to non-in-memory test builds and possibly help shake
> out test problems in regards to db-object conflicts earlier.  Also, in
> general we might decide to hook in after each class to drop schemas
> (ultimately HHH-8451 is a better solution to both of these I think).
> Anything else to consider here?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list