This is an exercise I’ve used to demonstrate how awkward unit testing can be if you can’t use a mocking framework. It’s an almost real work life situation (disclaimer: you should perhaps use container based authentication and JAAS) where we’re using API:s in a Java EE Server, adding two collaborators and then writing the logic combining it all.
No group has (yet) completed the entire task within 90 minutes – you might want to start/focus on using one collaborator only (I suggest the LDAP collaborator).
Originally posted on codingdojo.org.
When cleaning up a folder at work, I found this old document – it’s some form of a logical flow chart of the filter to write.
Here we go …
Background
In this Kata, your a programmer at ABC Corp and you’re making a new web app from scratch. After the head architect started working on this, it’s now up to you to make sure these tasks are completed:
- allow authentication using request parameters
- all authentication/login attempts should be verified agains LDAP
- successful logins should be recorded in the single sign on registry
However, you’re not the only programmer (team) adressing this web app, so the LDAP is written by another team and what you have right now is this interface:
public interface LdapAuthenticationGateway {
boolean credentialsAreValid(String userName, String password);
}
and the single sign on registry is also written by another team, leaving you with this interface:
public interface SingleSignOnRegistry {
boolean tokenIsValid(String token);
String registerNewSession(String userName);
void endSession(String token);
}
Your job basically is to write one or more javax.servlet.Filter that handles incoming requests and act according to whether there’s a cookie with a SSO token, username+password parameters etc.
It’s assumed that there’s some form of DependencyInjection framework in place – to get a handle to the SingleSignOnRegistry or the LdapAuthenticationGateway, you’ll simply have to provide something like:
public void setSingleSignOnRegistry(SingleSignOnRegistry registry) {
...
}
About this kata
This “real life” scenario has been used to demonstrate how mocking (using Mockito) can be useful. We’ve combined it with BDD and JDojo@Gbg will try to practice TDD using this kata (without mocking) next time around.
(“Real life” is quoted – proper JEE authentication should be tied into the container etc etc … The point with this exercise is that it’s fairly easy to explain how it should work and what needs to be done here with “real” Java EE API:s, and then focus on the “How to develop” aspect (TDD), but also to show/talk about the difference between mocking and stubbing.)