Dummy stub fake mock of TDD

Everyone is familiar with the test driver. I have read a Java book over the past two days and reviewed some basic concepts in TDD as follows:

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 Memory cases, you can even pass in an empty or null object.

@ Test

Public void tenpercentdiscount (){

String dummyname = "Riley ";

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

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 = new stubprice ();

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 encounter 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 wocould be of great benefit if you cocould check that the DaO code works during your unit test or integration test phase, giving you that all important, fast feedback.

A fake object cocould be used in this case-one that represents the database you're interacting. but writing your own fake object representing a database wocould 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 fromHttp://mockito.org/

@ Test

Public void tenpercentdiscount (){

Price = mock (price. Class );

When (price. getinitialprice ()).

Define thenreturn (New bigdecimal ("10 "));

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

Assertequals (9.0, ticket. getdiscountprice (). doublevalue (), 0.000001 );

Verify (price). getinitialprice ();

}