Google Testing Blog: January 2009

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 interface class CondorMotherhoodRoleInterface {
public:
  virtual Carrion* GiveFood() = 0;
  virtual SomeReturnTypes* OtherMomBehaviors() = 0;
};single-use fakeonly behaviors we need for this particular test class 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

2 comments

When to use Dependency Injection

Tuesday, January 20, 2009

Miško Hevery The 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.

13 comments

TotT: Use EasyMock

Thursday, January 08, 2009

Welcome back! We trust you all had a good holiday season and are ready for more TotTs -- DaveATM public interface Atm {
  boolean enterAccount(String accountNumber);
  boolean enterPin(String pin);
  boolean enterWithdrawalAmount(int dollars);
}recording and replaying public 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

7 comments

Interfacing with hard-to-test third-party code

Wednesday, January 07, 2009

Miško Hevery Hi 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

1 comment

Testing Blog

TotT: Keep Your Fakes Simple

When to use Dependency Injection

TotT: Use EasyMock

Interfacing with hard-to-test third-party code

Labels

Archive

Feed