Tag Archives: Agile

Spike: Stubs and Mocks

Writing unit test is an important part of development. An important part of unit testing is utilizing stubs and mocks in order to decouple various integrations and focus only on the logic in a particular method. Previously I went more in-depth on the topic in this article. Here in this development spike I demonstrate the basic concepts of stubbing and mocking objects in Unit tests.

You can find the source for this spike in SVN here

Environment Setup

Quick note on my project setup. I’m using Eclipse Helios with the m2Eclipse Maven plugin.

I use the JUnit and Mockito libraries in this example. If you want to include the jars manually you can get them here . Just download the jar and add it to your lib and classpath. I’m using maven and have already included the dependency in my pom.xml as

  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <type>jar</type>
    <scope>compile</scope>
   </dependency>
   <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.8.5</version>
    <type>jar</type>
    <scope>compile</scope>
   </dependency>

So in this example I’m using this idea that we have some order object that can calculate its total by iterating over items and applying appropriate tax. In this scenario the tax is pulled from a remote tax service, and I have some local implementation that’s managing all the connection logic separately.

The Object Under Test

Here is the method we’re going to test:

  public double calculateOrderTotal() throws Exception { double subTotal = 0.0; for (int i=0; i

In order to manage this code better and make it more flexible I’m allowing the taxService to be set by adding a setter method. This can typically be added to most existing code without impacting the current functionality.

Existing code:

  private TaxService taxService=new USTaxService();

Augmented with setter:

  private TaxService taxService=new USTaxService(); public void setTaxService(TaxService taxService) { this.taxService=taxService; }

Testing with a Stub

One challenge with testing this calculate function is that we’re relying on the USTaxservice to be up d. What if it’s not functioning or we’re just working in an offline setup and can’t connect. Wouldn’t it be nice to be able to still test our code? This is where stubs come in.

In this example we setup and use a fake Stub object rather than a real USTaxService. Our stub doesn’t do anything, it just returns a predefined response.

  TaxService taxService = mock(TaxService.class); stub(taxService.getTaxRate()).toReturn(.06); order.setTaxService(taxService);

First you see that we’re setting a local variable using a Mockito function “mock” to give us something that looks like a TaxService class.
Next we start to define how that stub should respond when it’s called. In this case we’re saying Stub out the getTaxRate function on our fake object. Whenever anyone calls it just return .06.
Finally we inject our fake taxService in the order Object.

When we exercise the test our code will use the stub and only exercise the logic in the method and not try to make any other system calls.

  assertEquals(expectedResult, actualResult, acceptableDeviation);

Testing with Mocks

How can we be sure the code in the method actually behaved like it should? In many situations our methods may act on other object but never return anything. This is where mocks come in.

A mock is used to verify the behavior inside a method. For this example I want to verify that my method called the getTaxRate function on the tax service. Frequently developers might try to inspect the concrete TaxService itself but why not use a mock?

In this example we’ll create a mock object inject it into the Object under test, then we’ll ask that mock object if anyone ever called a specific method on it. If our Order object did what it was supposed to, our mock object will report back that yes, my getTaxRate function was called.

We create a mock object and inject it like we did previously:

  TaxService taxService = mock(TaxService.class); stub(taxService.getTaxRate()).toReturn(.06); order.setTaxService(taxService);

Now we ask it if anyone called the getTaxRate Function:

            verify(taxService).getTaxRate();

Mocks and stubs are a great way to decouple your integrations for testing. While the examples shown here are minimal in nature, the tools are very robust and able to suit most scenarios.

Here is the full code:

OrderTest.java

import static org.junit.Assert.*;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.stub;
import static org.mockito.Mockito.verify;

import org.junit.Test;

public class OrderTest {

        @Test
       public void testCalculateOrder() throws Exception{
       // This is a typical test execution using a real service
       // This test shows what our code would look like BEFORE using a stub

            Order order = new Order();

            TaxService taxService = new USTaxService();
            order.setTaxService(taxService);

            Item item = new Item();
            item.setPrice(20.00);
            order.addItem(item);

            double expectedResult = 21.20;
            double actualResult = order.calculateOrderTotal();
            double acceptableDeviation = .01;

            assertEquals(expectedResult, actualResult, acceptableDeviation);

        }

        @Test
       public void testCalculateUsingMock() throws Exception{
            Order order = new Order();

            TaxService taxService = mock(TaxService.class);
            stub(taxService.getTaxRate()).toReturn(.06);     

            order.setTaxService(taxService);

            Item item = new Item();
            item.setPrice(20.00);
            order.addItem(item);

            double expectedResult = 21.20;
            double actualResult = order.calculateOrderTotal();
            double acceptableDeviation = .01;

            assertEquals(expectedResult, actualResult, acceptableDeviation);
            verify(taxService).getTaxRate();

        }
}

Order.java

import java.util.ArrayList;
import java.util.List;
import java.util.Map;

public class Order {

    private TaxService taxService;
    private List items = new ArrayList();

    public void setTaxService(TaxService taxService) {
        this.taxService=taxService;

    }

    public double calculateOrderTotal() throws Exception {

        double subTotal = 0.0;
        for (int i=0; i<items.size(); i++){
            subTotal += items.get(i).getPrice();
        }
        subTotal += subTotal * taxService.getTaxRate();
        return subTotal;
    }

    public void addItem(Item item) {
        this.items.add(item);

    }

}

Coffee Notes: Art of Development – Refactoring

“Entropy always wins. Eventually, chaos turns your beautifully imagined and well-designed code into a big mess of spaghetti. At least, that’s the way it used to be, before refactoring.” -James Shore and Shane Warden

Refactoring is such an important part of developement but too many developers either shy away from it or mistake refactor with rewrite.

James Shore has written multiples books on software development practices. In his book with coauthor Shane Warden titled The Art of Agile Development, they discuss a wide variety of development practices.

Shore has posted excerpts of the book online and a Fantastic discussion on refactoring.

I highly recomend reading James Shore’s article on Refactoring


Whats on Your Book Shelf – Agile

Whats on you Bookshelf - Blog post by Christopher GrantSo one thing I always find intersting is hearing about what everyone has on their bookshelf. So I thought I’d provide a list of some really good books I’ve been devouring recently, and hopefully hear back on what you all are reading.

Drop a comment with what’s on your bookshelf?

Here are some Agile books I’ve been reading recently. Continue reading


Coffee Notes: How to Build an Agile Dev Team – The GE Way

“Building software in a waterfall approach, where there is a big milestone release at the end of the process, isn’t conducive to success in the modern world, according to top executives from the NYSE and GE.” –Kerner

This article by Sean Michael Kerner reviews interviews with Robert Kerner, vice-president at New York Stock Exchange (NYSE), and Matt Merchant, CTO, GE Corporate on software development practices in their companies.

An interesting and view on what happens when leaders “get it”.

How to Build an Agile Dev Team – The GE Way


Coffee Notes: Negotiating Scrum Through Watefall

Coffee Notes: Negotiating Scrum Through Watefall - Blog entry by Christopher Grant -Here’s an interesting article about how to really deal with many of the challenges faced when dealing with Waterfall cultures and new Agile concepts. In his article Phil Southward lists out many of the key SDLC phases as well as how Agile teams can work through them in a wartefall organization.
It’s an interesting and enlightening read.
qaheaven (@qaheaven)
10/21/10 2:38 AM
Negotiating #Scrum Through a Waterfallhttp://bit.ly/aE86Zt

 

http://www.scrumalliance.org/articles/189-negotiating-scrum-through-a-waterfall


Coffee Notes: Seven Wastes of Software Development

Seven Wastes of Software Development Here’s an interesting article on the Seven Wastes of Software Development

In the article, Matt Stine, discusses the concepts of eliminating waste, first as it was presented in the Toyota Production System then expanding the idea into the world of software development. This series discusses Mary and Tom Poppendieck’s mapping of Shigeo Shingo’s “Seven Wastes of Lean Manufacturing” into the software development world.
Stine proposes the seven Wastes of Software development include:

  1. Partially Done Work
Waste
  2. Extra Features
Waste
  3. Relearning
Waste
  4. Handoffs
Waste
  5. Delays
Waste
  6. Task Switching
Waste
  7. Defects

It’s really a good read. You should take a moment to check it out:

http://mattstine.com/2010/11/10/the-seven-wastes-of-software-development/


Continuous Delivery through Latent Code, Feature Bits, Dormancy

blueCode.jpg

Continuous delivery is the concept of regularly producing output rather than building up a series of changes for one big release. To simplify the idea, think about monthly release of a project rather than one major release at the end. While we may like to think we are the only one coding in an application, that’s not the case. By leaving code in a state where it can’t go into product we lock up the release and add risk to all the other initiatives trying to go into production. A better practice is to use latent code and feature bits to make your code dormant, thus reducing risk and continuously deliver value. Lets look at some of the techniques.

Continue reading


Follow

Get every new post delivered to your Inbox.