In my opinion, this is working as it should. When the tests run, they create a Pizza that references your Base. The clue is at the bottom of com.pizza.domain.BaseIntegrationTest.txt in target/surfire-reports.
Code:
Caused by: java.sql.SQLException: Integrity constraint violation FK65BDC883CAA6D19 table: PIZZA in statement [delete from base where id=? and version=?]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2694)
... 52 more
If this was a real application, you would not allow the end user to delete a base that is in use, but would instruct them to change the Bases in all existing Pizzas, and then allow them to delete the offending Base. Of course, you would write unit tests to cover that scenario.
Of course, if you just want to see that the tests all pass, modify the ManyToOne annotation like so:
Code:
@ManyToOne(targetEntity = Base.class, cascade=CascadeType.ALL)
That way the unit tests will clean up the Bases as they delete the Pizzas. However, in a real world application, this may not be what you want.
Hope that helps.