Using Gradle to augment your legacy Ant build
January 4th, 2011
Gradle is a powerful build tool that can be used as a replacement for Ant. This article describes the benefits of moving to Gradle and a simple way to do so.
Lately I’ve been talking to developers on their philosophy to unit testing the code they write. These conversations start of in high level generalities and then quickly get to their testing practices in the Grails space (since that is where I spend most of my time these days). However, to much of my chagrin these conversations have usually ended with the line - “I see the value that unit testing brings, but…”
The “buts” range anywhere from “I don’t have time” to “Grails starts up so fast that I just test everything through the UI” to ” to “All the dynamic stuff makes it hard for me to figure out how to write the test”.
Admittally the documentation around grails testing is a little light and some of the meta-programming mojo going on behid the covers can be a litte intimidating or confusing for those new to the framework, but falling back on these excuses will enevitably leave you and your app in a bad place.
Now let’s see if we can do someting about that.
Initally I thought of constraint testing as “too simple to fail”, like testing getters or setters in Java. Plus back in the day (pre 1.0) this was a gigantic pain to even think about doing it properly. Now it’s so easy that you might as well do it.
Setting constraints in your domain class do 3 things for you.
+ inList + max + min + maxSize + minSize + nullable + range + scale + size + unique
+ blank + creditCard + email + matches + url + validator
So lets say we have this Person Domain Object:
class Person{
String firstName
String lastName
String userName
String password
Address address
static constraints = {
firstName(nullable:false, blank:false, max:50, min:2)
lastName(nullable:false, blank:false)
userName(nullable:false, blank:false, unique:true)
password(nullable:false, blank:false, min:8, max:20, matchs:/[a_zA-Z1-0]+/)
}
}
Here is how we would test the constraints:
class PersonConstraintsTest extends GrailsUnitTestCase{ **//1**
def person
void setUp(){
super.setup() **//2**
mockForConstraintsTests(Person) **//3**
person = new Person(firstName:"Jon",
lastName:"Smith",
userName:"jonsmith",
password:"weakpassword") **//4**
}
void testFirstNameNullable_Pass(){
assertTrue 'validation shoud have passed ' , person.validate() **//5**
}
void testFirstNameNullable_Fail(){
person.firstName = null
assertFalse 'validation shoud have faild' , person.validate() **//5**
assertEqual 'should have a nullable error', 'nullable', person.errors["firstName"]**//6**
}
//...
void tearDown(){
super.tearDown() //7
}
}
You would then follow this pattern for the rest of the constraints.
So that’s how you test your constraints. Super easy.
Now here is what happings begind the covers:
By extending the GrailsUnitTestCase and calling the super.setUp() method we get a map to hold our errors.
Here is what Grails does when we call the mockForConstraintsTests method and pass it our Domain class:
All the metaClass mojo is taken care of for you and all you have to write is 3 little lines:
P.S. All of this works just the same for testing the constraints on your Command Objects.
If you want to further dig into all of this testing goodness; download the latest version of Grails (anything after 1.1) souces and look at these classes: - GrailsUnitTestCase - Mockutils
Gradle is a powerful build tool that can be used as a replacement for Ant. This article describes the benefits of moving to Gradle and a simple way to do so.
Insert BLOB Data into HSQLDB via ANT Groovy plugin for JUnit testing
Have you ever been on a grails/groovy project that failed because of * limitations/faults in the technology itself * the grails/groovy learning curve Colin Harrington, a Senior Consultant at Object Partners, responds to a common question that we hear based on his years of experience.
Insert bio here