Integration tests behave differently to the application with respect to HibernateSession

[boardbloke]

Feature description

If we run a Grails application the OISV pattern means that we always have a HibernateSession associated with the thread.

INSERT and SELECT calls inside a service class that are not marked @transactional will work because a transaction is not mandatory. For an INSERT you can call domainObject.save() and that will not complain, but if you call DomainObject.save(flush:true) it will complain that you need to have a transaction. So far so good.

However in an integration test if you do not have the @Rollabck annotation you have neither a Session nor a Transaction. If in an integration test you call an application method that does a SELECT - i.e. something that works in a running application - the integration test will fail with "No HibernateSession bound to thread.

If on the other hand, if you add a @Rollback annotation to the test, that provides a session, but also starts a transaction. In that case a service method in the application that does not have @transaction, but does DomainObject.save(flush:true) will fail in the application at runtime, but succeed in the integration test - because there is a transaction provided by the test.

So - as far as I am aware - its not immediately easy to have an integration test that runs application code with the same transactional context that the application has. Depending on whether you add @Rollback or not you can get tests that fail when thy should pass and vice versa.

Best I could come up with is to not have @Rollback on the integration test and spray a lot of DomainObject.withNewSession { test code here} into the test - but that is horrible if using Spock.

It would be nice if by default the integration test bound a HIbernateSession to the test thread - i.e. provide a transaction context that aligns with the application.

If not by default then perhaps as an annotation @WithSession - or similar

[jdaugherty]

I've had this same problem. A quick solution for your project would to be introduce a method interceptor (AbstractMethodInterceptor) from Spock so that it does withSession { } around every method call. The issue is then how do you handle roll back? The @Rollback annotation exists to help clean-up data.

An alternative route is to clean-up data if you need it, and then use withSession {} when you need it. The way my team has handled this is we added a DatabaseCleanupInterceptor that is invoked after each test. This then removes the need for the @Rollback and only cleans up data if the test decides to add it.

This is the relevant clean up method we call from our interceptor:

    /**
     * Truncate all tables that have been modified since initialization (or last truncation)
     * @return map keyed by table name with a row count of the rows truncated
     */
    static Map<String, Long> truncateDatabase(ApplicationContext applicationContext, String dataSourceName = "dataSource") {
        Map<String, Long> tableRowCount = [:].withDefault { 0 }
        DataSource dataSource = lookupDataSource(applicationContext, dataSourceName)
        if (dataSource) {
            Sql sql = new Sql(dataSource)
            try {
                sql.execute('SET ' + 'REFERENTIAL_INTEGRITY FALSE')
                sql.eachRow("SELECT table_name, row_count_estimate FROM information_schema.tables WHERE table_schema = 'TESTDB' AND row_count_estimate > 0") { row ->
                    log.debug("Truncating table: ${row.table_name}")
                    tableRowCount[row.table_name] += row.row_count_estimate
                    sql.executeUpdate('truncate table ' + row.table_name)
                }

                // Clear the 2nd layer cache if it exists
                def sessionFactory = applicationContext.getBean("sessionFactory", SessionFactory)
                sessionFactory?.cache?.evictAllRegions()
            }
            finally {
                try {
                    sql.execute('SET ' + 'REFERENTIAL_INTEGRITY TRUE')
                    sql.close()
                }
                catch (e) {
                    log.error("Error cleaning up after cleaning up database", e)
                }
            }
        }

        tableRowCount
    }

[jdaugherty]

FYI adding @Rollback does cause a transaction to be added. It's just for the scope of that test method. If the test is creating data and not finding it, it's likely because the created objects aren't applying flush: true when saving or the code is setting up data in setup() which will rollback at the end of setup.

The issue I often have is if testing a process that has withNewTransaction then the data will never be found because the test transaction never finishes. This is why we use the clean-up approach so we can test across transactions if performing end to end functional tests.

[boardbloke]

Hey @jdaugherty - thanks for the detailled response!!

The issue for me is really about being confident that an integration test is (by default) running application code with an execution context that mirrors what an application is going to encounter. I.e if it passes the integration test, its going to work in production.

I can live with having to jump through extra hoops to setup and tear down test fixture data to achieve that - it makes sense to me that that is part of the test.

The spock interceptor sounds interesting - I'll look at that - thank you for the pointer. Just wish there was a more idiomatic Grails way to do it! :-).

[boardbloke]

Spock extensions are nice!!

This, for anybody else interested -
https://blog.pchudzik.com/201907/spock-extensions/