|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
@RunWith(JUnit4.class)
public class RiderManagerOldTest {
private RiderManager riderManager;
private HibernateTemplate hibernateTemplate = Mockito.mock(HibernateTemplate.class);
@Before
public void setup() {
this.riderManager = new RiderManager(this.hibernateTemplate);
}
@Test
public void generate() {
this.riderManager.generate(2);
List <Rider> allRiders = this.riderManager.findAll();
Assert.assertThat(allRiders.size(), CoreMatchers.is(2));
}
}
Specs2 is a Scala testing framework written by Eric Torreborre. Rather than tests, testing in Specs2 is based on specifications. Like unit testing, Specs2 lets you focus on and verify the expected behavior of a single class via unit specifications. Alternately, you can verify the entire system, via acceptance specifications (see Resources).
Using Specs2, you can write the body of a Java application test and execute it. As with JUnit, Specs2 lets you configure automated build tools to execute Specs2 specifications as part of the build process. Tests in Specs2 are written in Scala, a boon to developers who prefer more concise tests written in a more natural language.
Specs2 is well integrated with JUnit. In fact, you can utilize JUnit to execute Specs2 test code, just by annotating your
specification classes with @RunWith(classOf[JUnitRunner]). The JUnit runner specifies that JUnit will run the specifications; however, the body of the Specs2 specification remains
full Specs2 code. There is no need for @Test, @Before, and other JUnit annotations.
Specs2 is available under the MIT license; Specs2 Spring is available also under the MIT license.
Specs2 Spring is an extension of Specs2 that makes it simpler to test Spring applications written in Java or Scala. Specs2 Spring includes code that will help you set up the context for an entire integration test. The appropriate entries in the JNDI environment, as well as the beans under test, are autowired into the instance of the test under execution. Specs2 Spring also can be configured to run every example in its own transaction that rolls back automatically when the example completes.
We can get started with Specs2 Spring by writing unit specifications that verify the behavior of our Spring components. Consider
this test of the RiderManager class, which uses Spring's HibernateTemplate dependency with mock objects via Mockito.
class RiderManagerUnitSpec extends Specification with Mockito {
private val hibernateTemplate = mock[HibernateTemplate]
private val riderManager = new RiderManager(hibernateTemplate)
"The RiderManager should" {
"findAll Riders" in {
// setup the mock of HibernateTemplate here
riderManager.findAll.size() must_==(0)
}
"generate generate n Riders" in {
riderManager.generate(2)
there was two(hibernateTemplate).saveOrUpdate(any[Rider])
}
}
}
Note that the specification in Listing 3 is essentially a behavior-driven development (BDD) specification (see Resources). It is a more expressive equivalent of a standard unit test. Writing unit tests (or specifications) means writing a lot of code, especially in a system whose components have many dependencies between them. To get more bang out of specification code, let's see what happens when we switch from unit testing to integration testing.