The article presents a perspective and some code samples on how one could some cool stuff with Test-driven development (TDD) and Mocking. The code samples are done in Java.

Lets briefly understand what is TDD and mocking?

What is TDD?

Test-driven development, simply speaking, is a software development process in which developers write tests first and, then writing enough code to pass those tests. Once all of the tests pass, they do code refactoring to enhance code quality. Following are key advantages of adopting TDD as your development process:

1. Enforces the developers to thoroughly think through various different test cases which could be used to test the functional/business requirements. It, thus, takes care of lot of bugs that could be found during QA and post-production phases which are very difficult to fix.
2. Developers get to work very closely with both, business analyst and test engineers. This propagates team work.
3. Code refactoring can be done in easy way.

Following diagram represents TDD process:

Test-driven development (Courtesy: Wikipedia)

Following are some good pages on the web to get yourself going with TDD:

• 30 Days of TDD
• Introduction to Test Driven Development (TDD)
• Test-driven development

Unit Test Written First

Looking at the requirements, one could come up with some of the following tests:

1. restaurantNotCreatedDueToValidationFailure
2. restaurantNotCreatedDueToPersistenceFailure
3. restaurantCreated

Following is how the unit test (written first) looks like:

Unit Test: NewRestaurantTest.java

public class NewRestaurantTest {

@Before
public void setUp() throws Exception {
}
@After
public void tearDown() throws Exception {
}
@Test
public void restaurantCreated() {
}
@Test
public void restaurantNotCreatedDueToValidationFailure() {
}
@Test
public void restaurantNotCreatedDueToPersistenceFailure() {
}

}

Class Design

Looking at above tests, following different classes came into picture:

1. NewRestaurant: Comprising of logic to create the restaurant
2. Restaurant: Domain object representing the restaurant
3. RestaurantValidation: Consisting of validation logic matching the business rules required to add a new restaurant
4. RestaurantDAO: Consisting of logic to persist restaurant object into database

Java Class: NewRestaurant.java

Note the createRestaurant method in which validated and persist methods are called on classes RestaurantValidation and RestaurantDAO respectively. These methods are, however, empty methods in their respective classes. However, with these methods, the flow for creating the restaurant is complete. Look at the code below.

public Restaurant createRestaurant( Restaurant restaurant ) {
Restaurant retRest = null;
if( resVal.validated( restaurant ) ) {
if( resDAO.persist( restaurant ) ) {
retRest = new Restaurant( restaurant );
}
}
return retRest;
}

To test the above code, following code demonstrates the usage of mocking. Note how validated and persist methods on RestaurantValidation and RestaurantDAO respectively are mocked in three different tests shown below.

Unit Test: NewRestaurantTest.java

@Test
public void restaurantCreated() {
Restaurant restaurant = new Restaurant();
Mockito.when( restVal.validated(restaurant)).thenReturn( true );
Mockito.when( restDAO.persist(restaurant)).thenReturn( true );

Restaurant newRest = newRestaurant.createRestaurant(restaurant);
Mockito.verify( restVal ).validated(restaurant);
Mockito.verify( restDAO ).persist(restaurant);
assertNotNull( newRest );
}

@Test
public void restaurantNotCreatedDueToValidationFailure() {
Restaurant restaurant = new Restaurant();
Mockito.when( restVal.validated(restaurant)).thenReturn( false );
Mockito.when( restDAO.persist(restaurant)).thenReturn( true );

Restaurant newRest = newRestaurant.createRestaurant(restaurant);
Mockito.verify( restVal ).validated(restaurant);
Mockito.verify( restDAO, Mockito.never() ).persist(restaurant);
assertNull( newRest );
}

@Test
public void restaurantNotCreatedDueToPersistenceFailure() {
Restaurant restaurant = new Restaurant();
Mockito.when( restVal.validated(restaurant)).thenReturn( true );
Mockito.when( restDAO.persist(restaurant)).thenReturn( false );

Restaurant newRest = newRestaurant.createRestaurant(restaurant);
Mockito.verify( restVal ).validated(restaurant);
Mockito.verify( restDAO ).persist(restaurant);
assertNull( newRest );
}

Thus, as a summary, if you would want to have greater fun with TDD, make use of mocking as it allows you to simulate some interesting behaviors without the need for writing any code.