Java Reference
In-Depth Information
and IntelliJ IDEA. It also can be retrieved from the Maven central repository, using a POM
dependency of the form
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
</dependency>
As an alternative, JUnit version 4.5 and above enables the artifact ID junit -dep instead,
which does not include the so-called Hamcrest matchers ( http://code.google.com/p/ham-
crest/ ) that simplify the syntax in certain cases. Like most cool projects, the source code for
JUnit now resides at GitHub, at https://github.com/junit-team/junit.
Most of the Gradle build files in this topic (especially for the projects in this chapter)
include JUnit as a “test-compile” dependency. That means classes in the API (like
org.junit.TestCase and org.junit.Assert ) are only available for test classes.
When writing JUnit tests in Groovy, you have two options. You can write a JUnit test
with annotations as usual, but implement it in Groovy, or you can extend the
GroovyTestCase class. The only difference is that GroovyTestCase adds a few ad-
ditional methods to the TestCase class from JUnit.
Because this topic is all about integration, I'd like to examine the following cases:
• Use a standard Groovy JUnit test to check a Java implementation.
• Use a standard Java JUnit test to check a Groovy implementation.
• Write a Groovy test that extends GroovyTestCase to see what additions it
provides.
In each case I need something to test. Because I plan to mix the languages, one way I've
found that makes that easier is to declare my methods in a Java interface and then imple-
ment it in both languages. That's actually a pretty general rule.
Groovy implements Java
Groovy classes can implement Java interfaces as easily as Java classes can.
Search WWH ::




Custom Search