{"id":290,"date":"2009-11-05T00:30:34","date_gmt":"2009-11-04T19:00:34","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=290"},"modified":"2016-12-19T15:04:55","modified_gmt":"2016-12-19T09:34:55","slug":"grails-few-tips-for-writing-integration-tests","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/grails-few-tips-for-writing-integration-tests\/","title":{"rendered":"Grails: Few tips for writing integration tests"},"content":{"rendered":"

Just thought I would share with you few tips or key points we should remember while writing integration test cases:<\/p>\n

1.\u00a0 Flush and clear the session object for every single test case for example<\/p>\n

\n
\n
class FooTests extends GroovyTestCase {\r\n  def sessionFactory\r\n  void setUp() {\r\n    sessionFactory.currentSession.flush()\r\n    sessionFactory.currentSession.clear()\r\n  }\r\n}<\/pre>\n<\/div>\n<\/div>\n
2.\u00a0 Drop and create the test database before you run integration test: Recently I found, after commiting my integration tests in the repository, some started failing and to my surprise, at the same time that failing test passed on my machine. Later I discovered it was because of some database issue. Since then I have made it a practice to drop and recreate the database again before commiting it to the repository, and then run the test cases\u00a0to ensure that all test passes.<\/p>\n
\n
\n
drop database <myTestDatabase>;\r\ncreate database <myTestDatabase>;\r\n\r\n<\/pre>\n<\/div>\n<\/div>\n
Note :If you use in-memory database you may not need to follow this step.<\/p>\n
3. \u00a0Make different test cases to test different methods or even parts of it defined in a controller or a service: for example<\/p>\n
\n
\n
 void testAccountService_addSavingsAccount() {...}\r\n void testAccountService_addCheckingAccount() {...}\r\n void testAccountService_addSavingsAccount_invalidName() {...}  \/\/to test the expected exceptions<\/pre>\n<\/div>\n<\/div>\n
This would make your test cases more understandable and focussed on individual task.<\/p>\n
4.\u00a0 Avoid making your test case depedent upon the data. Otherwise there is high probability that it would break if any changes were made to the data<\/p>\n
Lets have a look at the sample\u00a0code for Integration test written for the controller:<\/p>\n
\n
\n
class AccountControllerTests extends GrailsUnitTestCase {\r\n    def accountService\r\n    def sessionFactory\r\n    def renderMap\r\n    def controller\r\n\r\n    protected void setUp() {\r\n        super.setUp()\r\n        controller = new AccountController()\r\n        controller.accountService = accountService\r\n        sessionFactory.currentSession.flush()\r\n        sessionFactory.currentSession.clear()\r\n        AccountController.metaClass.render = {Map map ->\t\/\/This is to access model when view or template is rendered in the controller\r\n            renderMap = map\r\n        }\r\n    }\r\n   public void testSave() {\r\n        def oldCount = Account.list().size()\r\n        loadParams()\r\n        controller.save()\r\n        assertEquals \"Created a new account\", renderMap.model.status \/\/accessing model values rendered with view\/template\r\n        assertEquals(oldCount + 1, Account.list().size())   \/\/not being dependent on the data\r\n    }\r\n\r\n   private void loadParams() {\r\n        def params = [routeTransit: '789456124', accountNumber: '23444', accountType: \"ACH\",...]\r\n        controller.params.putAll(params)\r\n    }\r\n}<\/pre>\n<\/div>\n<\/div>\n
Hope this helped!<\/p>\n
Cheers!
\n~~Amit Jain~~
\namit@intelligrape.com
\nIntelliGrape Softwares
\nhttp:\/\/www.tothenew.com<\/p>\n","protected":false},"excerpt":{"rendered":"
Just thought I would share with you few tips or key points we should remember while writing integration test cases: 1.\u00a0 Flush and clear the session object for every single test case for example class FooTests extends GroovyTestCase { def sessionFactory void setUp() { sessionFactory.currentSession.flush() sessionFactory.currentSession.clear() } } 2.\u00a0 Drop and create the test database […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":9},"categories":[7],"tags":[143,4840,142],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/290"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=290"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/290\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}