TDD之Dummy Stub Fake Mock

测试驱动大家都很熟悉了，这两天正好看了一个java的书，对TDD中的一些基本概念进行了复习，具体如下: 

Dummy	An object that is passed around but never used. Typically used to fulfill the parameter list of  a method.
Stub	An object that always returns the same canned response. May also hold some dummy state.
Fake	An actual working implementation (not of production quality or configuration) that can replace the real implementation.
Mock	An object that represents a series of expectations and provides canned responses.

Dummy

A  dummy   object  is  the  easiest  of  the  four  test  double  types  to  use.  Remember,  it’s designed  to  help  fill  parameter  lists  or  fulfill  some  mandatory  field  requirements where you know the object will never get used. In many cases, you can even pass in an empty or null object. 

 @Test

  public void tenPercentDiscount() {

    String dummyName = "Riley";        

    Ticket ticket = new Ticket(dummyName,  new BigDecimal("10"));

    assertEquals(new BigDecimal("9.0"), ticket.getDiscountPrice());

  }

Stub object

You typically use a stub  object when you want to replace a real implementation with an

object that will return the same response every time. Let’s return to our theater ticket

pricing example to see this in action.

 @Test

  public void tenPercentDiscount() {

Price price = new StubPrice(); 

 Ticket ticket = new Ticket(price);           

    assertEquals(9.0,

                 ticket.getDiscountPrice().doubleValue(),

                0.0001);       

  }

public class StubPrice implements Price {

  @Override

  public BigDecimal getInitialPrice() {

    return new BigDecimal("10");         

  }

}

Fake object

A  fake  object can be seen as an enhanced stub that almost does the same work as your production code, but that takes a few shortcuts in order to fulfill your testing require -ments. Fakes are especially useful when you’d like your code to run against something that’s very close to the real third-party subsystem or dependency that you’ll use in the live implementation

 Most well-grounded Java developers will sooner or later have to write code that interacts with a database, typically performing CRUD  operations on Java objects. Prov-ing that your Data Access Object ( DAO) code works before running it against the pro-duction database is often left until the system integration test phase, or it isn’t checked at all! It would be of great benefit if you could check that the  DAO code works during your unit test or integration test phase, giving you that all important, fast feedback.

 A fake object could be used in this case—one that represents the database you’re interacting with. But writing your own fake object representing a database would be quite  difficult!  Luckily,  over  recent  years,  in-memory  databases  have  become  small enough, lightweight enough, and feature-rich enough to act as a fake object for you.

HSQLDB (www.hsqldb.org) is a popular in-memory database used for this purpose.

Mock object

Mock  objects  are  related  to  the  stub  test  doubles  that  you’ve  already  met,  but  stub objects are usually pretty dumb beasts. For example, stubs typically fake out methods so that they always give the same result when you call them. This doesn’t provide any way to model state-dependent behavior.

Mockito  (available  from  http://mockito.org/

 @Test

  public void tenPercentDiscount() {

    Price price = mock(Price.class);          

    when(price.getInitialPrice()).

         ➥ thenReturn(new BigDecimal("10"));           

    Ticket ticket = new Ticket(price, new BigDecimal("0.9"));

    assertEquals(9.0, ticket.getDiscountPrice().doubleValue(), 0.000001);

    verify(price).getInitialPrice();

  }