The Benefits of Using assertThat over other Assert Methods in Unit Tests
September 18th, 2013
The released of JUnit 4.4 added a new method assertThat which is a much improved way to write assertions vs the old assert methods.
Grails GORM has solid support for using multiple datasources in both 1.3.x with the Datasources plugin, and 2.x with built-in multi-datasource support. This feature allows you to partition your Domain classes and Services to attach to two or more databases. One pitfall you’ll encounter though, is that Integration Tests of the secondary datasources DO NOT rollback their transactions on versions of Grails < 2.3 (GRAILS-9771). However, we can borrow the approach from the 2.3 patch to fix our pre 2.3 test classes!
The approach is simply to add rollback steps for the autowired transactionManager in the JUnit test setUp() and tearDown() methods (or Spock setup() and cleanup()). In this example I have a datasource named “db2” so the injected name of the bean is transactionManager_db2. The test then gets a reference to the transactionStatus in setUp() and rolls it back in tearDown(). (Note: this code was written for a Grails 1.3 app but should also work in 2.x)
/*
Grails will not rollback transactions on secondary datasources in integration tests
on versions prior to version 2.3.x. (http://jira.grails.org/browse/GRAILS-9771)
But using the solution from the JIRA ticket, you can get this to work on
Grails < 2.3.x, and on Grails 1.3.x with the datasources plugin
*/
class GrailsMultipleDatasourcesWithRollbackIntTests extends GroovyTestCase {
/**
* for a second datasource named 'db2', Grails creates this transactionManager_db2
*/
def transactionManager_db2
def transactionStatus
/** Just some service that uses the db2 datasource */
def myDb2StuffService
void setUp() {
super.setUp()
transactionStatus = transactionManager_db2.getTransaction(new DefaultTransactionDefinition())
}
void tearDown() {
super.tearDown()
transactionManager_db2.rollback(transactionStatus)
}
void testSomeServiceMethod() {
//Do your test and it will now rollback
}
}
Of course the downfall of this approach is that you must remember to setup each test class for a non-default datasource (or use a base test class hierarchy). But this code is essential for integration testing your secondary databases until the app has been migrated to Grails 2.3!
As a reference, here is the configuration I was using for the Datasources plugin in Grails 1.3:
/*
Sample Datasources.groovy file for datasources 0.5 plugin with grails 1.3.x
*/
datasources = {
datasource(name: 'db2') {
domainClasses([com.sheetsj.domain.db2.MyObj, com.sheetsj.domain.db2.MyObj2])
services(['myDb2Stuff'])
driverClassName('com.ibm.db2.jcc.DB2Driver')
dialect(org.hibernate.dialect.DB2Dialect)
url('jdbc:db2://server:port/dbname:currentSchema=schemaName')
username('jdbcUser')
password('jdbcPass')
logSql(true)
hibernate {
cache {
use_second_level_cache(false)
use_query_cache(false)
}
}
}
}
The released of JUnit 4.4 added a new method assertThat which is a much improved way to write assertions vs the old assert methods.
How to get the benefits of type-safe page objects with the Geb functional testing framework
Discussion of Groovys Optional Typing system with benefits and drawbacks outlined.
Jeff has developed Java, Groovy, Grails, and Javascript web apps for industries as varied as Defense, Energy, Weather, Insurance, and Telecom. He is a co-organizer of the Omaha Java Users Group. Jeff has worked on Grails projects since the Grails 1.3.x days, and has experience with production Groovy code as well as Spock tests and Gradle builds. His latest focus has been on AngularJS and Spring Boot applications using JHipster. Jeff also enjoys volunteering at local CoderDojo events to teach programming to our next generation.