Over a million developers have joined DZone.

GrUnit: inline tests in Groovy

DZone's Guide to

GrUnit: inline tests in Groovy

· Java Zone
Free Resource

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

I love tests. I need tests. But I need easier way to write tests. Inline tests is a way to write test directly in the Groovy source code. This article is direct continualtion of GrUnit: Groovy way of unit testing and almost everything described there is applicable to inline tests.

So what is inline test?

Inline test is snippet of code inside class/constructor/method annotation, which leads to creation of test class right from source code. There are two main reasons why is it useful. First of all creation of tests require some ceremony (to create test class in separate test directory, create test methods) an we are lazy (at least I am). But may be more important is that when we develop API of the class it is often very convinient to write some test cases (and we don't want to switch to another file for that)

Let me show you one example, which tells more than thousand words

@Field Calculator calc
setUp { calc = [] }
class Calculator {
private ArrayList<Double> list = []

assertEquals(10d, calc.push(10d).list[-1])
Calculator push(double v) {

shouldFail { calc.peek() }
double peek() {

testFailIfEmpty{ shouldFail { calc.pop() } }
testPushPop {
assertEquals(10d, calc.push(10d).pop())
assertEquals(0, calc.list)
double pop() {

assertEquals (4d, calc.push(4d).peek())
testPlusNull{ assertEquals (10d, calc.push(6).plus().peek()) }
testPlusNonNull {assertEquals (10d, calc.plus(6).peek())}
Calculator plus(Double value = null) {
push((value == null ? pop () : value) + pop ())

If you had time to read my previous article about GrUnit then most probably you can imagine what's going on - we generate static inner class extending GroovyTestCase and create test method as specified by @GrUnit annotation. Please refer to mentioned article for details about setUp () and accumulated tests.

Here is screenshort of IntelliJ after running tests - all together we have created 7 tests (and btw, nice documentation right in the code)

 There is small trick here. Careful reader can notice on the screenshot groovy.util.test.GrUnitTestSuite. Unfortunately IDE knows nothing about our generated test classes, so we need to do a little bit of work to create run configuration for our tests. Easiest way to do it is to specify groovy.util.test.GrUnitTestSuite as test class and provide VM parameter -Dgroovy.test.dir="out/production/Examples" which instruct where to find compiled test classes

Another important thing to notice: compiled classes for inline tests will be placed together with compiled sources. So after compilation You might decide to move everyting related to inline tests to class directory of test. Any build system normally capable to do that. File mask "*$GrUnitTest*.class" will do the job

GrUnit is very young tool but we plan to use it actively in Groovy++. I can also imagine that if proved to be useful at some point it can be migrated in to Groovy Core

Thank you for reading and till next time

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}