Showing posts with label User Story. Show all posts
Showing posts with label User Story. Show all posts

Saturday, July 13, 2013

Mockito Tutorial: TDD Framework for Mocking Functionality and Verifying User Stories

Overview:
This article looks at Mockito, a popular mocking framework for testing your Java code. Mockito API promotes writing clean and readable tests.

Here, we will look at a simple example how you could leverage the Mockito API to mock functionality in your tests.

Sample code can be found here.

Project Structure:
 org.fazlan.mockito.sample  
 ├── pom.xml  
 └── src  
   ├── main  
   │   └── java  
   │       └── org  
   │           └── fazlan  
   │               ├── CreditChecker.java  
   │               ├── CreditCheckException.java  
   │               └── Order.java  
   └── test  
     └── java  
       └── org  
         └── fazlan  
           └── OrderTest.java  

Step 1: Creating the Project

 mvn archetype:generate -DartifactId=org.fazlan.mockito.sample -DgroupId=org.fazlan -Dversion=1.0-SNAPSHOT -DinteractiveMode=false  

Step 2: Updating the Maven dependencies

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  
  <modelVersion>4.0.0</modelVersion>  
  <groupId>org.fazlan</groupId>  
  <artifactId>org.fazlan.mockito.sample</artifactId>  
  <version>1.0-SNAPSHOT</version>  
  <packaging>jar</packaging>  
  <name>mockito-sample</name>  
  <url>http://maven.apache.org</url>  
  <properties>  
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>  
  </properties>  
  <dependencies>  
    <dependency>  
      <groupId>org.testng</groupId>  
      <artifactId>testng</artifactId>  
      <version>6.8.5</version>  
      <scope>test</scope>  
    </dependency>  
    <dependency>  
      <groupId>org.mockito</groupId>  
      <artifactId>mockito-core</artifactId>  
      <version>1.9.5</version>  
    </dependency>  
  </dependencies>  
 </project>  

Step 3: Defining the User story for placing an order

The following is a simple user story for placing an order, the story is based on an ordering system.

The story assumes that the system has clients and they have credit accounts associated with them. To successfully place an order, the clients should have sufficient funds, otherwise, the processing would fail. Thus, a credit check is performed before placing the order.

 Narrative:  
 In order to purchase goods for my needs  
 As a credit worthy client  
 I want to place an order

Step 4: Writing the test to verify the story

The following is a simple test for verifying the story. It's decorated using Mockito annotations, and they keep the code clean and easy to read.

 package org.fazlan; 
 
 import org.mockito.InjectMocks;  
 import org.testng.annotations.BeforeMethod;  
 import org.testng.annotations.Test;  
 import java.util.UUID; 
 
 import static junit.framework.Assert.assertEquals;  
 import static junit.framework.Assert.assertNotNull;  
 import static org.fazlan.Order.createOrderFor;
  
 import static org.mockito.Mockito.*;  
 import static org.mockito.MockitoAnnotations.Mock;  
 import static org.mockito.MockitoAnnotations.initMocks;  

 public class OrderTest {  

   private String clientNumber;  
   //injected by mockito  
   @Mock  
   private CreditChecker creditChecker;
  
   @InjectMocks  
   private Order order;  

   @BeforeMethod  
   public void setUp() {  
     //given  
     generateClientNumber();  
     order = createOrderFor(getClientNumber());  
     //initialises the mocks and injects them to the designated targets
     initMocks(this);
   }  

   @Test  
   public void shouldCreateOrderGivenClientNumber() {  
     //then  
     assertNotNull(order);  
     assertEquals(clientNumber, order.getClientNumber());  
   }  

   @Test(expectedExceptions = {CreditCheckException.class})  
   public void shouldNotPlaceTheOrderGivenClientCreditCheckFails() {  
     //given  
     theCreditCheckWouldThrowExceptionWhenCalled();  
     //when  
     order.place();  
   }  

   @Test  
   public void shouldPlaceTheOrderGivenClientCreditCheckPasses() {  
     //given  
     theCreditCheckWouldPassWhenCalled();  
     //when  
     order.place();  
     //then  
     assertNotNull(order.getOrderNumber());  
     verify(creditChecker).check(getClientNumber());  
   }  

   private void theCreditCheckWouldThrowExceptionWhenCalled() {  
     doThrow(new CreditCheckException()).when(creditChecker).check(getClientNumber());  
   }  

   private void theCreditCheckWouldPassWhenCalled() {  
     doNothing().when(creditChecker).check(getClientNumber());  
   }  

   private void generateClientNumber() {  
     clientNumber = UUID.randomUUID().toString();  
   }  

   private String getClientNumber() {  
     return clientNumber;  
   }  
 }  

IMPORTANT NOTE: 
Here, the CreditChecker is just an Interface, and there is no implementation. It could be either the implementation is not available at this point of time or, it's been developed by someone else, which we really don't care.

 package org.fazlan;  

 public interface CreditChecker {  
   void check(String clientNumber);  
 }  

However, what we are interested is in how the order placement functionality would react based on the outcome of the credit check. Thus, we can use Mockito to mock the credit check and make it behave the way we intend in order to test our logic while placing an order.

This is the beauty of a mocking framework, without having to implement the actual details you can still work on your tests. This is specially true in a TDD environment, where you want to  test a piece of code in isolation without having to care about it's infrastructure code or dependencies.

Step 5: Using Mockito to mock and verify the story

The tests are self-explanatory, and now lets take a close look the code.

   @Mock   
   private CreditChecker creditChecker;  

   @InjectMocks   
   private Order order;   

   @BeforeMethod   
   public void setUp() {   

    //given   
    generateClientNumber();   

    order = createOrderFor(getClientNumber());   

    //initialises the mocks and injects them to the designated targets  
    initMocks(this);  
   }   

The above code basically says, that the test should perform the following, and for each test (since it's been annotated with @BeforeMethod in testng framework), it should create an instance of an Order and initialise it with the mocked CreditChecker.
  • @Mock - Mock the interface CreditChecker. During the runtime, Mockito will generate a proxy that acts as an actual implementation of the interface and make it behave as we have specified.
  • @InjectMocks - Inject the mocked dependencies used in this instance. (e.i: creditChecker).
  • initMocks(this) - Initialise the above annotations for mocks and the target instance to be injected with in this test instance.
Lets assume, our business logic is such that if the client has insufficient funds, then the credit check should fail by throwing an CreditCheckException, otherwise, it'll do nothing.

Based on the above business logic, we advise the Mockito framework to behave exactly as per our expectation when we perform the credit check logic for different scenarios.

Scenario: When the credit check fails:

Here, we advise the Mockito framework to throw a CreditCheckException exception when the check() operation is called on the mocked creditCheck instance, so that we can test our order placement logic when credit check fails.

   @Test(expectedExceptions = {CreditCheckException.class})  
   public void shouldNotPlaceTheOrderGivenClientCreditCheckFails() {  
     //given  
     theCreditCheckWouldThrowExceptionWhenCalled();  
     //when  
     order.place();  
   }  
  
   private void theCreditCheckWouldThrowExceptionWhenCalled() {  
     doThrow(new CreditCheckException()).when(creditChecker).check(getClientNumber());  
   }  
 

Scenario: When the credit check passes:

Similarly, here we advise the Mockito framework to do nothing when the check() operation is called on the mocked creditCheck instance.

   @Test  
   public void shouldPlaceTheOrderGivenClientCreditCheckPasses() {  
     //given  
     theCreditCheckWouldPassWhenCalled();  
     //when  
     order.place();  
     //then  
     assertNotNull(order.getOrderNumber());  
     verify(creditChecker).check(getClientNumber());  
   } 

   private void theCreditCheckWouldPassWhenCalled() {  
     doNothing().when(creditChecker).check(getClientNumber());  
   }  

You can find more about the Mockito API documentation here.

Step 6: Based on the above tests, we can develop our Order.java as follows,

Following is a simple implementation of the Order.java, that has a method called 'place' to place the order against a given client.

 package org.fazlan;  
 
 import java.util.UUID;  

 //domain driven entity - @see DDD - Domain Driven Design for more.  
 public class Order {  

   private String orderNumber;  
   private String clientNumber;  
   private CreditChecker creditChecker;  

   private Order(String clientNumber) {  
     this.clientNumber = clientNumber;  
   }  

   public void place() {  
     doCreditCheck();  

     assignOrderNumber();  

     //do some processing and save the order  
   }  

   private void doCreditCheck() {  
     creditChecker.check(getClientNumber());  
   }  

   private void assignOrderNumber() {  
     orderNumber = UUID.randomUUID().toString();  
   }  

   public static Order createOrderFor(String clientNumber) {  
     return new Order(clientNumber);  
   }  

   public String getClientNumber() {  
     return clientNumber;  
   }  

   public String getOrderNumber() {  
     return orderNumber;  
   }  

   protected void setCreditChecker(CreditChecker creditChecker) {  
     this.creditChecker = creditChecker;  
   }  
 }  

Summary:
This was a brief article on how to make use of Mockito as a framework for mocking functionality in your tests in a TDD environment.

Sample code can be found here.

Sunday, June 2, 2013

jBehave Tutorial: BDD Framework for Verifying User Stories

Overview:
This article looks at jBehave, a popular BDD framework for Java.

There are many ways in which you could configure jBehave. Here, we look at the minimal set of configuration required to get the framework integrated with your BDD environment.

Sample code can be found here.

Project Structure:

org.fazlan.jbehave.exmaple
├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── org
    │           └── fazlan
    │               └── jbehave
    │                   └── exmaple
    │                       └── Calculator.java
    └── test
        ├── java
        │   └── org
        │       └── fazlan
        │           └── jbehave
        │               └── exmaple
        │                   ├── steps
        │                   │   └── AddTwoNumbersSteps.java
        │                   └── stories
        │                       └── CalculatorStories.java
        └── resources
            └── org
                └── fazlan
                    └── jbehave
                        └── exmaple
                            └── stories
                                └── calculator_stories.story

Step 1: Creating the Project

 mvn archetype:generate -DartifactId=org.fazlan.jbehave.exmaple -DgroupId=org.fazlan -Dversion=1.0-SNAPSHOT -DinteractiveMode=false  

Step 2: Updating the Maven dependencies
Update (2013-10-7) : Updated to include maven-jbehave-plugin.

NOTE: This assumes that you run only acceptance tests at maven integration-test phase, any unit tests will be skipped as per the pom.xml configuration.

 <?xml version="1.0" encoding="UTF-8"?>  
 <project xmlns="http://maven.apache.org/POM/4.0.0"  
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  
   <modelVersion>4.0.0</modelVersion>  
   <groupId>org.fazlan</groupId>  
   <artifactId>org.fazlan.jbehave.exmaple</artifactId>  
   <version>1.0-SNAPSHOT</version>  
   <properties>  
     <jbehave.version>3.8</jbehave.version>  
     <junit.version>4.11</junit.version>  
     <failsafe.and.surefire.version>2.16</failsafe.and.surefire.version>  
   </properties>  
   <dependencies>  
     <dependency>  
       <groupId>junit</groupId>  
       <artifactId>junit</artifactId>  
       <version>${junit.version}</version>  
     </dependency>  
     <dependency>  
       <groupId>org.jbehave</groupId>  
       <artifactId>jbehave-core</artifactId>  
       <version>${jbehave.version}</version>  
     </dependency>  
   </dependencies>  
   <build>  
     <plugins>  
       <plugin>  
         <groupId>org.apache.maven.plugins</groupId>  
         <artifactId>maven-surefire-plugin</artifactId>  
         <version>${failsafe.and.surefire.version}</version>  
         <configuration>  
           <!-- Disable unit tests -->  
           <skip>true</skip>  
         </configuration>  
       </plugin>  
       <plugin>  
         <groupId>org.apache.maven.plugins</groupId>  
         <artifactId>maven-failsafe-plugin</artifactId>  
         <version>${failsafe.and.surefire.version}</version>  
         <executions>  
           <execution>  
             <id>integration-test</id>  
             <goals>  
               <goal>integration-test</goal>  
               <goal>verify</goal>  
             </goals>  
           </execution>  
         </executions>  
         <configuration>  
           <includes>  
             <include>**/*Stories.java</include>  
           </includes>  
         </configuration>  
       </plugin>  
       <plugin>  
         <groupId>org.jbehave</groupId>  
         <artifactId>jbehave-maven-plugin</artifactId>  
         <version>${jbehave.version}</version>  
         <executions>  
           <execution>  
             <id>run-stories-as-embeddables</id>  
             <phase>integration-test</phase>  
             <configuration>  
               <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>  
               <includes>  
                 <include>**/*Stories.java</include>  
               </includes>  
               <ignoreFailureInStories>false</ignoreFailureInStories>  
               <ignoreFailureInView>false</ignoreFailureInView>  
             </configuration>  
             <goals>  
               <goal>run-stories-as-embeddables</goal>  
             </goals>  
           </execution>  
         </executions>  
       </plugin>  
     </plugins>  
   </build>  
 </project>  

Step 3: Defining the User story

A User story describes the behaviour of a piece of software and the expected outcome (acceptance criteria) for a given set of preconditions.

The following contains a simple user story for adding two numbers, which is defined in org/fazlan/jbehave/exmaple/stories/calculator_stories.story

 Narrative:  
 In order to quickly find out the sum of two numbers  
 As a user  
 I want to use a calculator to add two numbers
  
 Scenario: Add two valid numbers
  
 Given a calculator  
 When I add <number1> and <number2>  
 Then the outcome should <result>
  
 Examples:  
 |number1|number2|result|  
 |10|10|20|  

Step 4: Writing the test to verify the story

The following is the JUnit test for verifying and testing our add two numbers story.

 package org.fazlan.jbehave.exmaple.stories; 
 
 import org.fazlan.jbehave.exmaple.steps.AddTwoNumbersSteps; 
 
 import org.jbehave.core.configuration.Configuration;  
 import org.jbehave.core.junit.JUnitStory;  
 import org.jbehave.core.reporters.StoryReporterBuilder;  
 import org.jbehave.core.steps.InjectableStepsFactory;  
 import org.jbehave.core.steps.InstanceStepsFactory;  

 import static org.jbehave.core.reporters.Format.CONSOLE;  
 import static org.jbehave.core.reporters.Format.TXT;
  
 public class CalculatorStories extends JUnitStory {
  
   @Override  
   public Configuration configuration() {  
     return super.configuration()  
         .useStoryReporterBuilder(  
             new StoryReporterBuilder()  
                 .withDefaultFormats()  
                 .withFormats(CONSOLE, TXT));  
   }  

   // Here we specify the steps classes  
   @Override  
   public InjectableStepsFactory stepsFactory() {  
     return new InstanceStepsFactory(configuration(), new AddTwoNumbersSteps());  
   }  
 }  


IMPORTANT NOTE: By default, jBehave framework will look for *.story files defined in the same package as the corresponding *Stories.java file.

e.i: org.fazlan.jbehave.exmaple.stories.CalculatorStories.java will look for a *.story file called org/fazlan/jbehave/exmaple/stories/calculator_stories.story

Assume, you have defined your story in a file called 'CalculatorStory.story' then you can change the default behaviour of discovering stories by overriding the List<String> storyPaths() method in the following way,

 package org.fazlan.jbehave.exmaple.stories;  

 import org.fazlan.jbehave.exmaple.steps.AddTwoNumbersSteps;  

 import org.jbehave.core.configuration.Configuration;  
 import org.jbehave.core.junit.JUnitStory;  
 import org.jbehave.core.reporters.StoryReporterBuilder;  
 import org.jbehave.core.steps.InjectableStepsFactory;  
 import org.jbehave.core.steps.InstanceStepsFactory;  

 import static org.jbehave.core.reporters.Format.CONSOLE;  
 import static org.jbehave.core.reporters.Format.TXT;  

 public class CalculatorStories extends JUnitStory {  

   @Override  
   public Configuration configuration() {  
     return super.configuration()  
         .useStoryReporterBuilder(  
             new StoryReporterBuilder()  
                 .withDefaultFormats()  
                 .withFormats(CONSOLE, TXT));  
   }  

   // Here we specify the steps classes  
   @Override  
   public InjectableStepsFactory stepsFactory() {  
     return new InstanceStepsFactory(configuration(), new AddTwoNumbersSteps());  
   }  

   @Override  
   protected List<String> storyPaths() {  
     return new StoryFinder().findPaths(org.jbehave.core.io.CodeLocations.codeLocationFromPath("src/test/resources"), "**/CalculatorStory.story", "");  
   }  
 }  

Step 5: Writing the jBehave Step that verifies your story
There are multiple ways to write jBehave Steps, but in this article we focus on keeping this simple and write our Steps as POJOs.

 package org.fazlan.jbehave.exmaple.steps;  

 import org.fazlan.jbehave.exmaple.Calculator;  

 import org.jbehave.core.annotations.Given;  
 import org.jbehave.core.annotations.Named;  
 import org.jbehave.core.annotations.Then;  
 import org.jbehave.core.annotations.When;  

 public class AddTwoNumbersSteps {  

   private Calculator calculator;  

   @Given("a calculator")  
   public void givenACalculator() {  
     calculator = new Calculator();  
   }  

   @When("I add <number1> and <number2>")  
   public void whenIAddNumber1AndNumber2(@Named("number1")int number1, @Named("number2")int number2) {  
     calculator.add(number1, number2);  
   }  

   @Then("the outcome should <result>")  
   public void thenTheOutcomeShould(@Named("result")int result) {  
     assert calculator.getResult() == result;  
   }  
 }  

Step 6: Implementing the Calculator.java to meet our User story acceptance criteria
Following is a simple implementation of a Calculator that has a method called 'add' to add two numbers.

 package org.fazlan.jbehave.exmaple;
  
 public class Calculator {  

   private int result;  

   public void add(int number1, int number2) {  
     result = number1 + number2;  
   }  

   public int getResult() {  
     return result;  
   }  
 }  


Step 7: Running your tests
You can run the acceptance tests issuing the following Maven command.

mvn clean integration-test

Summary:
This was a brief article on how to integrate jBehave with Maven for BDD with your application.

Sample code can be found here.