concept test case in category java

This is an excerpt from Manning's book JUnit in Action MEAP V06. Login to get full access to this book.

Now that you are writing test cases, it is time to measure how good these tests are by using a test coverage tool to report what code is executed by the tests and what code is not. I also discuss how to write code that is easy to test and finish by taking a first look at Test Driven Development (TDD).

Figure 7.3 Adding a test case and replacing the real web resource with a stub

The next approach in testing the SampleServlet is running the test cases where the HttpServletRequest and HttpSession objects live: in the container itself. This approach eliminates the need to mock any objects; we simply access the objects and methods we need in the real container.

This is an excerpt from Manning's book JUnit in Action, Second Edition. Login to get full access to this book.

Test class (or TestCase or test case)—A class that contains one or more tests represented by methods annotated with @Test. Use a test class to group together tests that exercise common behaviors. In the remainder of this book, when we mention a test, we mean a method annotated with @Test; when we mention a test case (or test class), we mean a class that holds these test methods—a set of tests. There’s usually a one-to-one mapping between a production class and a test class.

Notice that the IDs are dynamically defined using EL expressions, so the test cases succeed regardless of the order in which they’re executed.

Listing 18.10. Entity mapping unit tests for User and Telephone classes

,	As explained earlier, we opted for manual transaction control, so the test case explicitly starts and finishes the transaction.
	Because we’re testing the entity mappings and not the real persistence layer code such as DAO implementations, we deal with the persistence manager directly.
	Once the object is read from the database, we assert that it has the expected values, using our old friend EntitiesHelper ; id and phoneId (which are defined in the superclass and have the initial value of 1) are updated to reflect the objects that were loaded from the database. If they aren’t updated, the next test case could fail (if it saves objects, which is the case in our example).
	The test case for saving an entity is pretty much orthogonal to the load entity test case; nothing new here.

Although these tests run fine and pass, the way the IDs (id and phoneId) are handled is far from elegant and presents many flaws. For instance, if a test case fails, the IDs aren’t updated, and then other tests running after it will fail as well. Sure, a try/ finally block would fix this particular issue, but that would make the test even uglier and more verbose. Another problem is that testSaveUserWithTelephone() doesn’t update the IDs (because its dataset assertion would fail), so a third test case would probably fail.

When that happens, you, the developer, are going to curse Hibernate, JPA, ORM, and (with a higher intensity) this book’s authors: you followed our advice and created unit tests for both the Façade and DAO classes in isolation, but once one called the other in real life, a JPA exception arose! Unfortunately, situations like these are common. Just because you wrote test cases, it doesn’t mean your code is bug free. But on the bright side, because you have a test case, it’s much easier to reproduce and fix the issue. In this case, the exception is caused because the User/Telephone relationship is defined as lazy, which means the telephones were not fetched by the JPA queries and are loaded on demand when getTelephones() is called. But if that method is called outside the JPA context, an exception is thrown. So, to simulate the problem in the test case, we change testGetUserByIdWithTelephone() to clear the context after committing the transaction:

@Test
@DataSets(setUpDataSet="/user-with-telephone.xml")
public void testGetUserByIdWithTelephone() throws Exception {
  beginTransaction();
  long id = ELFunctionMapperImpl.getId(User.class);
  User user = dao.getUserById(id);
  commitTransaction(true);
  assertUserWithTelephone(user);
}

Running the test case after this change fails because of the same exception our poor user faced in the real application. The solution then is to fix the JPA query to eagerly fetch the telephones, as shown here:

Back to our test cases, the dataset files contain references to the ID columns (both as primary key in the users table and foreign key on telephones), and because we’re using the same dataset for both load and save, the ID values must be defined dynamically at the time the test is run. If we used distinct datasets, the IDs wouldn’t matter on the load test (because JPA wouldn’t be persisting entities, only loading them), and for the save tests, we could ignore them. The problem with this option is that it makes it harder to write and maintain the test cases. It would require two datasets and also changes in the DataSetsTemplateRunner.assertDataSet() method in order to ignore the ID columns. Because our goal is always to facilitate long-term maintenance, we opted for using the same dataset, and hence we need a solution for the ID synchronization problem.

Listing 18.10 tried to solve the problem the simplest way, by letting the test case update the IDs, but that approach had many issues. A better approach is to integrate the dataset ID’s maintenance with the JPA’s entity ID’s generation, and there are two ways to achieve such integration: taking control of ID generation or being notified of the generated IDs.