The class-level annotation is used to instruct how to load ApplicationContext, and is used by WebApplicationContext from the default location as file:/src/main/webapp. The following code snippet shows the loading of resource to initialize WebApplicationContext to be used for testing:

@WebAppConfiguration("classpath: myresource.xml") 
public class TestClass{ 
  //code to test 
} 

Earlier, the developed test case used explicit Spring Context initialization. In this demo, we will discuss how to use SprinJUnit4ClassRunner and @RunWith. We will use the Ch07_JdbcTemplates_Testing project and the test methods of BookDAO_JdbcTemplates by following these steps:

1. Download the spring-test-5.0.0.RC1.jar file to use the Spring testing APIs.
2. Create SpringRunner_TestBookDAO_JdbcTemplate in the com.packt.ch07.tests package as a JUnit test case. Select BookDAO_JdbcTemplate as a class under test, and all of its methods under testing.
3. Annotate the class by the @RunWith and @ContextConfiguration annotations, as shown in the code given next.
4. Add a data member of type BookDAO, and apply the annotation for autowiring, as shown in the following code snippet:

       @RunWith(SpringJUnit4ClassRunner.class) 
       @ContextConfiguration("classpath:connection_new.xml") 
       public class SpringRunner_TestBookDAO_JdbcTemplate { 
         @Autowired 
         @Qualifier("bookDAO_jdbcTemplate") 
         BookDAO bookDAO_JdbcTemplate; 
 
         @Test 
         public void testAddBook() { 
           Book book = newBook("Book_Test", 909090L, "Test  
             Publication", 1000, "Test Book description", "Test  
             author"); 
           int rows_insert = bookDAO_JdbcTemplate.addBook(book); 
           assertEquals(1, rows_insert); 
         } 
       } 

The @RunWith annotation accepts SpringJUnit4ClassRunner. @ContextConfiguration accepts the file to initialize the container. Also, we use annotation-based autowiring for the BookDAO instance instead of using Spring API in the setUp() method, as we did in an earlier demo. The code for testing in testAddBook() remains the same, as we do not change the logic.

5. Execute it as the JUnit test, and if your ISBN is not already available in the Book table, the test will pass.

We just performed testing against the actual database, which makes it slower. These tests are not isolated from the environment, and they will always be dependent upon the external dependencies--in our case, on the database. Unit test cases are always written based on a few assumptions according to real-time values. To understand the problem and complexity while dealing with the real time values, let's take the example of the update function as discussed in the following section.

We have a function to update the book details. To update the book, the function has two arguments: first, to accept ISBN, and second, to update the price of the book with the specified ISBN, as you can see in the following code snippet:

public int updateBook(long ISBN, int updated_price() 
{ 
  // code which fires the query to database and update the price 
    of the book whose ISBN has specified 
  // return 1 if book updated otherwise 0 
} 

We wrote the test case to find out whether the book is updated or not, as shown here:

@Test 
public void testUpdatedBook() 
{ 
  long ISBN=2;   // isbn exists in the table 
  int updated_price=200; 
  int rows_updated=bookDAO.updateBook( ISBN, updated_price); 
  assertEquals(1, rows_updated); 
} 

We assumed that the ISBN exists in the database to update the book details. So, the test case is executed successfully. However, what if, in between, someone changes the ISBN or deletes the row with that ISBN? The test case written by us will fail. The problem is not in our test case; the only problem is that we assume that the ISBN exists.

Another thing is that, sometimes, the real-time environment may not be accessible. Controller testing is highly dependent upon the request and response objects. These requests and responses are initialized by the container once the application is deployed to the server. Either the server may not be available for deployment, or the layer on which the controller coding is dependent is not developed yet. All such problems make testing more and more difficult. These problems can be easily solved using mock object testing.