1

Say I have a test that asserts whether registration of a new user in the system actually succeeds:

RegistrationIntegrationTest#testRegister()

Now, this creates a new test user in the actual database, since I want this test to run on the actual environment. This means that the test must not be run all the time, right? How should I approach these kind of tests? Those that use the actual environment of the system and manipulates real data?

Julious Igmen
  • 268
  • 3
  • 9

1 Answers1

4

You could use one of the following:

  1. If possible use an in memmory database like hsqldb, which you can re-create or setup suitably for each TestSuite/TestCase
  2. If the methods under test are transactional, run the test case with spring junit rollback true
  3. If you cannot use 1 or 2, you can write a pre & post test sql script that will setup & then cleanup your db. You can use a framework like dbunit
Community
  • 1
  • 1
6ton
  • 4,174
  • 1
  • 22
  • 37
  • Wow. Cool stuff. One more thing, what if the feature is to be integration-tested by a client app? Say, what if a client app wants to create an automated integration test of its implementation of the registration API? Should the servers-side provide a way to determine whether a request is an integration test so it can provide or make use of an in-memory database? – Julious Igmen Jun 17 '15 at 23:49
  • 1
    @JuliousIgmen if you want an integration test of the client, you have two options: 1) create a fake server (and write tests that ensure it has reasonable behavior), or 2) start a real server with a fake or in-memory backend. The first option is less fragile and less flaky; the second covers more code and may require less maintenance – NamshubWriter Jun 18 '15 at 01:12