Showing posts with label testing. Show all posts
Showing posts with label testing. Show all posts

Saturday, May 16, 2009

Do you really need to test that?

We all know Kent Beck. The co-creator of JUnit, one of the founding fathers of the Agile Manifesto, author of several eXtreme Programming books, just to highlight a few. Now that Kent has spent a decade telling us all to test everything... now he says, it is ok to skip testing.

I'll let that sink in a bit.

What he is basically saying is that it is ok for the kids to play in the street, if they feel that it is safe. Of course Kent is a big kid, so he will use his experience to determine if it is ok for him to play in the street. But what about the kids that don't know better? You know who they are. They are the kids that climb the tree without thinking about how they are going to get down. They are the kids that lock themselves in the closet without thinking about how they are going to get out.

Kids will be kids. They will make poor decisions if you give them the chance. That is why there are parents. Our job is to make sure that they don't make stupid decisions. Or perhaps we let them make bad decisions to teach them a lesson, just as long as we can control the environment to ensure that nobody gets seriously hurt.

So now is the time to decide if you are a the parent or a the kid. And if you think that you are the parent, half of you are probably wrong. That is the nature of the child, to think they know everything.

One way to measure if you are the parent or the kid is to use the Dreyfus Model of Skill Acquisition. If you follow Andy Hunt, you may have seen him speak and write about this. The model is basically a set of five stages that you progress through from novice to master. It helps explain why novices need lots of rules, and why experts don't think they apply to them.

On the Dreyful Model I often rank myself at a 4 1/2, depending on the subject matter of course. It can be an interesting exercise to rank yourself on the scale, then let your friends rank you to see if you meet your expectations of greatness. Likely you won't, but that is ok, it is in our nature to be overly self-confident.

Now back to testing. Is it really ok to skip testing? Kent thinks so, but I wonder if the followers of the TDD "faith" think the same. In many shops there is no ambiguity, there are only absolutes. You must test they say, but do you? Kent Beck thinks it is a judgment call.

Now I don't have the right answer other than there is no black and white, instead it is all gray. You should acknowledge that, and not immediately attack someone who says that they didn't write a test. Instead ask them their reasoning. Perhaps it is a good reason, perhaps not, but don't come to conclusions.

Thursday, December 20, 2007

Testing Servlets with JUnit

In my day-to-day job I write a lot of unit tests, and I try to test everything I can. Recently though I had written a service that I was unable to test completely. One of the methods in the service had the job of sending an HTTP request to a remote server and responding with the results. For my project I used commons-httpclient to send the request.

@SuppressWarnings("unchecked")
public String sendHttpPost (String url, String queryString)
throws Exception
{
String result = null;

try {
HttpClient client = new HttpClient();
PostMethod post = new PostMethod(url);
post.setQueryString(queryString);
client.executeMethod(post);

result = post.getResponseBodyAsString();
post.releaseConnection();
}
catch (Exception e) {
throw new Exception("post failed", e);
}

return result;
}


If you have used commons-httpclient, this is about as simple as it gets, but I still wanted to have a unit test for it. So the problem became, "how can I test this method when it requires that I hit a web site". After some searching I found that the Jetty servlet-container has a ServletTester class just for this purpose.

In my Maven 2 I included the ServletTester using the following repository and dependency information. I always use Maven 2 as allows other developers to quickly set up their IDE and download all required JARs. If you don't use Maven, you will need to manually download all of the dependencies.

<repositories>
<repository>
<id>codehaus-release-repo</id>
<name>Codehaus Release Repo</name>
<url>http://repository.codehaus.org</url>
</repository>
</repositories>

...

<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-servlet-tester</artifactId>
<version>6.1.6</version>
<scope>test</scope>
</dependency>


With this in place the next step was writing the JUnit test cases. For me I wanted to initialize the servlet-container once, then run a set of tests against it. In JUnit 4 you can use the @BeforeClass and @AfterClass annotations to mark methods that should be executed before and after all of the tests.

public class HttpPostServiceTest
{
private static ServletTester tester;
private static String baseUrl;


/**
* This kicks off an instance of the Jetty
* servlet container so that we can hit it.
* We register an echo service that simply
* returns the parameters passed to it.
*/
@BeforeClass
public static void initServletContainer () throws Exception
{
tester = new ServletTester();
tester.setContextPath("/");
tester.addServlet(EchoServlet.class, "/echo");
baseUrl = tester.createSocketConnector(true);
tester.start();

}

/**
* Stops the Jetty container.
*/
@AfterClass
public static void cleanupServletContainer () throws Exception
{
tester.stop();
}
}


The code highlighted in blue is where we start an instance of the server. I created a new instance of the ServletTester, setting the context path and adding a servlet mapping. This alone does not bind the server to a port, for that you need to call createSocketConnector(true), which binds the server to a local port and returns the URL. The port used will be a high unused port. I save an instance of the ServletTester so that I can stop the service in the @AfterClass block, and I save the baseUrl so that I can target it in my tests.

The servlet I added to the container I called EchoServlet. This servlet simply echos the parameters passed to it.

public class EchoServlet extends GenericServlet
{

@SuppressWarnings("unchecked")
@Override
public void service (ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
PrintWriter out = response.getWriter();
Map<String, String[]> params =
new TreeMap<String, String[]>(request.getParameterMap());

out.println("SIZE=" + params.size());
for (Entry<String, String[]> entry : params.entrySet()) {
out.println(entry.getKey() + ":::"
+ StringUtils.join(entry.getValue(), ","));
}
}
}


The servlet takes the parameter map and creates a TreeMap out of it. The TreeMap is needed so that the parameter names are returned in sorted order. Being able to predict the order of the returned keys is required in order to test against the output of the servlet.

To finish things up, I just needed to write a unit test.

@Test
public void testPost () throws Exception
{
PostService svc = new PostService();

String res = svc.sendHttpPost(baseUrl + "/echo",
"foo=bar&baz=%25%26%3D%2F");
String[] resList = StringUtils.split(res, "\n");

assertEquals(3, resList.length);
assertEquals("SIZE=2", resList[0].trim());
assertEquals("foo:::bar", resList[1].trim());
assertEquals("baz:::%&=/", resList[2].trim());
}


After that, run the test and watch it work.