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();
}
