googletesting

Constructor Injection vs. Setter Injection

Thursday, February 19, 2009

Miško HeverySetter-InjectionConstructor-Injectioncircular dependenciesCreditCardProcessor processor = new CreditCardProcessor();OfflineQueue queue = new OfflineQueue();
CreditCardProcessor processor = new CreditCardProcessor();
processor.setOfflineQueue(queue);Database db = new Database();
OfflineQueue queue = new OfflineQueue();
queue.setDatabase(db);
CreditCardProcessor processor = new CreditCardProcessor();
processor.setOfflineQueue(queue);
processor.setDatabase(db);Database db = new Database();
db.setUsername("username");
db.setPassword("password");
db.setUrl("jdbc:....");
OfflineQueue queue = new OfflineQueue();
queue.setDatabase(db);
CreditCardProcessor processor = new CreditCardProcessor();
processor.setOfflineQueue(queue);
processor.setDatabase(db);CreditCardProcessor processor = new CreditCardProcessor(?queue?, ?db?);Database db = new Database("username", "password", "jdbc:....");
OfflineQueue queue = new OfflineQueue(db);
CreditCardProcessor processor = new CreditCardProcessor(queue, db);Model-View-Controller

To Assert or Not To Assert

Monday, February 9, 2009

Miško Heveryclass House {
Door door;
Window window;
Roof roof;
Kitchen kitchen;
LivingRoom livingRoom;
BedRoom bedRoom;

House(Door door, Window window,
Roof roof, Kitchen kitchen,
LivingRoom livingRoom,
BedRoom bedRoom){
this.door = Assert.notNull(door);
this.window = Assert.notNull(window);
this.roof = Assert.notNull(roof);
this.kitchen = Assert.notNull(kitchen);
this.livingRoom = Assert.notNull(livingRoom);
this.bedRoom = Assert.notNull(bedRoom);
}

void secure() {
door.lock();
window.close();
}
}testSecureHouse() {
Door door = new Door();
Window window = new Window();
House house = new House(door, window,
null, null, null, null);

house.secure();

assertTrue(door.isLocked());
assertTrue(window.isClosed());
}testSecureHouse() {
Door door = new Door();
Window window = new Window();
House house = new House(door, window,
new Roof(),
new Kitchen(),
new LivingRoom(),
new BedRoom());

house.secure();

assertTrue(door.isLocked());
assertTrue(window.isClosed());
}testSecureHouse() {
Door door = new Door();
Window window = new Window();
House house = new House(door, window,
new Roof(),
new Kitchen(new Sink(new Pipes()),
new Refrigerator()),
new LivingRoom(new Table(), new TV(), new Sofa()),
new BedRoom(new Bed(), new Closet()));

house.secure();

assertTrue(door.isLocked());
assertTrue(window.isClosed());
}null

TotT: Be an MVP of GUI Testing

Thursday, February 5, 2009

In MVC, the presentation logic is shared by Controller and ViewIn MVP, presentation logic is taken over entirely by a Supervising Controller, also known as a PresenterMVC

MVP

public CongressionalHearingView() {
testimonyWidget.addModifyListener(
new ModifyListener() {
public void modifyText(ModifyEvent e) {
presenter.onModifyTestimony(); // presenter decides action to take
}});
}
public class CongressionalHearingPresenter {
public void onModifyTestimony() {
model.parseTestimony(view.getTestimonyText()); // manipulate model
}
public void setWitness(Witness w) {
view.setTestimonyText(w.getTestimony()); // update view
}
}
more modular codeenables easy unit testing of the Presenter and the Viewpublic void testSetWitness() {
spyView = new SpyCongressionalHearingView();
presenter = new CongressionalHearingPresenter(spyView);
presenter.setWitness(new Witness(“Mark McGwire”, “I didn't do it”));
assertEquals( “I didn't do it”, spyView.getTestimonyText());
}
this episode

TotT: Keep Your Fakes Simple

Thursday, January 22, 2009

TEST_F(BabyCondorTest, EatsCarrion) {
  FakeCondor mother;
  scoped_ptr carrion;
  BabyCondor* pchick = &chick_;
  mother.Imprint(vector(&pchick, &pchick + 1)); // just one chick
  while(!chick_.HasFood()) {
    mother.Eat(); // disposes of any food the mother kept for herself
    mother.Scavenge(carrion.reset(new FakeCarrion)); // finds new food
    mother.RandomlyDistributeFoodAmongYoungAndSelf(); // feeds baby or mom
  }
  chick_.Eat();
  EXPECT_TRUE(carrion->WasEaten());
}a lot of setup!replicates too much functionalityextracting a role interfaceclass CondorMotherhoodRoleInterface {
public:
  virtual Carrion* GiveFood() = 0;
  virtual SomeReturnTypes* OtherMomBehaviors() = 0;
};single-use fakeonly behaviors we need for this particular testclass CondorFeedingPuppet: public CondorMotherhoodRoleInterface {
public:
  virtual Carrion* GiveFood() { return test_carrion_; }
  virtual SomeReturnTypes* OtherMomBehaviors() { return NULL; }
  Carrion* test_carrion_; // public var is tolerable in a one-off object
};

TEST_F(BabyCondorTest, EatsCarrion) {
  CondorFeedingPuppet mother; FakeCarrion test_carrion;
  mother.test_carrion_ = &test_carrion;
  chick_.ReceiveFood(&mother);
  chick_.Eat();
  EXPECT_TRUE(test_carrion.WasEaten());
}highly-focused fakeeasy and quick to writesimplermore readablethis episode

When to use Dependency Injection

Tuesday, January 20, 2009

Miško HeveryThe only thing that does not fully convince me in your articles is usage of Guice. I'm currently unable to see clearly its advantages over plain factories, crafted by hand. Do you recommend using of Guice in every single case? I strongly suspect, there are cases, where hand-crafted factories make a better fit than Guice. Could you comment on that (possibly at your website)?

Should I be using dependency-injection?

Should I be using manual dependency-injection or automatic dependency-injection framework?

Which automatic dependency-injection framework should I use?

Should I be using dependency-injection?yeshow to think about the new-operatorsingletons are liarsdependency-injectionShould I be using manual dependency-injection or automatic dependency-injection framework?In favor of manual DI:

Simple: Nothing to learn, no dependencies.

No reflection magic: In IDE it is easy to find out who calls the constructors.

Even developers who do not understand DI can follow and contribute to projects.

In favor of automatic DI framework:

Consistency: On a large team a lot can be said in doing things in consistent manner. Frameworks help a lot here.

Declarative: The wiring, scopes and rules of instantiation are declarative. This makes it easier to understand how the application is wired together and easier to change.

Less typing: No need to create the factory classes by hand.

Helps with end-to-end tests: For end-to-end tests we often need to replace key components of the application with fake implementations, an automated framework can be of great help.

Which automatic dependency-injection framework should I use?GUICEPico ContainerSpringYour milage may very.

TotT: Use EasyMock

Thursday, January 8, 2009

Welcome back! We trust you all had a good holiday season and are ready for more TotTs -- DaveATMpublic interface Atm {
  boolean enterAccount(String accountNumber);
  boolean enterPin(String pin);
  boolean enterWithdrawalAmount(int dollars);
}recording and replayingpublic void testAtmLogin() {
  Atm mockAtm = createMock(Atm.class); // 1
  EasyMock.expect(mockAtm.enterAccount("MyAccount")).andReturn(true); // 2
  EasyMock.expect(mockAtm.enterPin("1234")).andReturn(true); // 3
  EasyMock.replay(mockAtm); // 4
  Account account = new Account();
  account.login(mockAtm); // 5
  assertTrue(account.isLoggedIn());
  EasyMock.verify(mockAtm); // 6
} Atmreplay()Accountverify()falsestubnicethis episode

Interfacing with hard-to-test third-party code

Wednesday, January 7, 2009

Miško HeveryHi Misko, First I would like to thank you for the “Guide to Writing Testable Code”, which really helped me to think about better ways to organize my code and architecture. Trying to apply the guide to the code I’m working on, I came up with some difficulties. Our code is based on external frameworks and libraries. Being dependent on external frameworks makes it harder to write tests, since test setup is much more complex. It’s not just a single class we’re using, but rather a whole bunch of classes, base classes, definitions and configuration files. Can you provide some tips about using external libraries or frameworks, in a manner that will allow easy testing of the code?

-- Thanks, Shahar

There are two different kind of situations you can get yourself into:

Either your code calls a third-party library (such as you calling into LDAP authentication, or JDBC driver)

Or a third party library calls you and forces you to implement an interface or extend a base class (such as when using servlets).

Calling Third-Party Librariesjavax.naming.ldapinterface Authenticator {
boolean authenticate(String username,
String password);
}

We can easily implement an InMemoryAuthenticator for running our application in the QA environment.

If the third-party APIs change than those changes only affect our adapter code.

If we now have to authenticate against a Kerberos or Windows registry the implementation is straight forward.

We are less likely to introduce a usage bug since calling the ideal API is simpler than calling the original API.

Plugging into an Existing Framework

Servlets require a no argument constructor which prevents us from using dependency injection. See how to think about the new operator.

Servlets pass around HttpServletRequest and HttpServletResponse which are very hard to instantiate or mock.

class LoginPage {
Authenticator authenticator;
boolean success;
String errorMessage;
LoginPage(Authenticator authenticator) {
this.authenticator = authenticator;
}

String execute(Map<String, String> parameters,
String cookie) {
// do some work
success = ...;
errorMessage = ...;
}

String render(Writer writer) {
if (success)
return "redirect URL";
else
writer.write(...);
}
}

It does not inherit from any base class.

Dependency injection allows us to inject mock authenticator (Unlike the no argument constructor in servlets).

The work phase is separated from the rendering phase. It is really hard to assert anything useful on the Writer but we can assert on the state of the LoginPage, such as success and errorMessage.

The input parameters to the LoginPage are very easy to instantiate. (Map<String, String>, String for cookie, or a StringWriter for the writer).

LoginPageLoginServletLoginPageLoginSevletwiring bugLoginServletLoginPageclass LoginServlet extends HttpServlet {
Provider<LoginPage> loginPageProvider;

// no arg constructor required by
// Servlet Framework
LoginServlet() {
this(Global.injector
.getProvider(LoginPage.class));
}

// Dependency injected constructor used for testing
LoginServlet(Provider<LoginPage> loginPageProvider) {
this.loginPageProvider = loginPageProvider;
}

service(HttpServletRequest req,
HttpServletResponse resp) {
LoginPage page = loginPageProvider.get();
page.execute(req.getParameterMap(),
req.getCookies());
String redirect = page.render(resp.getWriter())
if (redirect != null)
resp.sendRedirect(redirect);
}
}global stateHttpServletRequestHttpServletResponseWaffleWebWork

Testing Blog

Constructor Injection vs. Setter Injection

To Assert or Not To Assert

TotT: Be an MVP of GUI Testing

TotT: Keep Your Fakes Simple

When to use Dependency Injection

TotT: Use EasyMock

Interfacing with hard-to-test third-party code

Labels

Archive

Feed

Company-wide

Products

Developers