by 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 Libraries javax.naming.ldap . It is a collection of several interfaces and classes, with a complex way in which you have to call them. If your code depends on this interface you will drown in mocking hell. Now I don't know why the API is so complex, but I do know that my application only needs a fraction of these calls. I also know that many of these calls are configuration specific and outside of bootstrapping code these APIs are cluttering what I have to mock out.interface 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).
LoginPage and all of the untestable mess is in the LoginServlet which acts like an adapter. We can than test the LoginPage in depth. The LoginSevlet is not so simple, and in most cases I just don't bother testing it since there can only be wiring bug in that code. There should be no application logic in the LoginServlet since we have moved all of the application logic to LoginPage .class 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 state , which is very bad, but in the case of servlets I have no choice. However, I make sure that only servlets access the global state and the rest of my application is unaware of this global variable and uses proper dependency injection techniques.HttpServletRequest and HttpServletResponse . For example Waffle and WebWork
The LoginSevlet is not so simple, and in most cases I just don't bother testing it since there can only be wiring bug in that code..
ReplyDeleteThat makes me jump, because part of my work is about using complex API and the application itself has only minimal intelligence.
I have to worry about a lot of wiring bugs, they are my daily business (especially since my own code is properly unit-tested). I find myself writing not really UnitTests but mostly functional tests, using UnitTest frameworks.