CODEWITHSUNDEEP
hibernateunit-testinggrailsgrails-ormgrails-domain-class
Cris
Cris

Reputation: 5007

Grails unit test of domain class (gorm)

Started playing with grails and I want to evaluate GORM, so I created a domain class using Spring Tool Suite: Client with name, vatNumber, and regNumber and the test class was created automatically.

The code for unit test I added is :

package pilot1

import grails.test.*

class ClientTests extends GrailsUnitTestCase {
    protected void setUp() {
        super.setUp()
    }

    protected void tearDown() {
        super.tearDown()
    }

    void testSomething() {
        def instances = []
        def myTestDomain = mockDomain(Client, instances)
        def client = new Client(name:"Test",vatNumber:"323",regNumber:"343")
        client.id =1;
        assertEquals client.name, "Test"
        client.save();
        def res = Client.findByName("Test")
        println instances
        println res
        //assertEquals 1, instances.size()
    }
}

The results are [] and null! What did I do wrong?

Also, I would like also to see the SQL generated by GORM (Hibernate) behind the scenes. Any idea how I might do that in Grails ?

Upvotes: 1

Views: 5493

Answers (4)

Ruben
Ruben

Reputation: 9120

Saving the client can fail without an exception being thrown, which would explain why res is null. Try the following code below, so you can see if and why saving the client failed.

client.save()
if(client.hasErrors()){
// Saving failed, look in client.errors to see the specific reason
}

Upvotes: 1

Ray Tayek
Ray Tayek

Reputation: 10003

don't do this: client.id =1;

save() will supply an id.

you may need to save(flush:true).

just do the save and use then use the id to do a get.

then do your testing.

this link may be useful: http://blog.springsource.com/2011/06/07/countdown-to-grails-1-4-unit-testing/

Upvotes: 2

Jim Norman
Jim Norman

Reputation: 749

First, you shouldn't be evaluating GORM itself. Those who provide Grails take on the responsibility for testing GORM. Granted, you probably didn't mean that anyway.

Second, testing findBy*() is not usually the concern for unit tests. If you do need to test findBy*(), you'll need to collect all of the findBy*() response instances and pass that list as the second argument to mockDomain(). You are using mockDomain() incorrectly in your example -- you must tell mockDomain() which instances to mock in order to receive them back in a findBy*() call.

Upvotes: 1

Cris
Cris

Reputation: 5007

http://www.ibm.com/developerworks/java/library/j-grails10148/index.html

"As I mentioned earlier, Grails supports two basic types of tests: unit and integration. There's no syntactical difference between the two — both are written as a GroovyTestCase using the same assertions. The difference is the semantics. A unit test is meant to test the class in isolation, whereas the integration test allows you to test the class in a full, running environment. Quite frankly, if you want to write all of your Grails tests as integration tests, that's just fine with me. All of the Grails create-* commands generate corresponding integration tests, so most folks simply use what is already there. As you'll see in just a moment, most of the things you want to test require the full environment to be up and running anyway, so integration tests are a pretty good default."

Upvotes: 1

Related Questions