Join the DZone community and get the full member experience.
Join For Freethe 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:
- 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.
- developers get to work very closely with both, business analyst and test engineers. this propagates team work .
- 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:
what is mocking?
mocking is a unit testing phenomenon which helps to test objects in isolation by replacing dependent objects with complex behavior with test objects with pre-defined/simulated behavior. these test objects are called as mock objects.
how does tdd shine with mocking?
in tdd, the primary objective is to pass the tests that are written first. however, in real world scenario, as one starts writing the code, one come across various cases which could be made as dependent classes. following are different options one can do:
- without mocking : write all code in the same class and pass the tests. once the tests pass, refactor the code by extracting methods and classes. make sure the tests pass.
-
with mocking
: instead of requiring to write all the code at once in the same class, just implement the flow by making use of dependent classes and make sure the tests pass. in doing this, just define the dependent classes, and mock them in unit tests. by doing this, one would ensure that method flow pass without having the need to write the entire code. the advantage of using mocking is the interesting behaviors that one could simulate without having need for the code. this is demonstrated later in this article with code samples. following diagram demonstrates the fact that with mocking, one may not need to write the dependent classes and still complete the code flow while making sure all the related tests pass.
software requirement
we will try and see how tdd shines with mocking with this requirement. the requirement is to add a new restaurant to a restaurant database system. one should be able to add a restaurant if the mandatory data are entered.
unit test written first
looking at the requirements, one could come up with some of the following tests:
- restaurantnotcreatedduetovalidationfailure
- restaurantnotcreatedduetopersistencefailure
- 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:
- newrestaurant: comprising of logic to create the restaurant
- restaurant: domain object representing the restaurant
- restaurantvalidation: consisting of validation logic matching the business rules required to add a new restaurant
- 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.
Published at DZone with permission of Ajitesh Kumar, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments