I don't mean that literally, what I do mean is a web developer should hate when Java's http specification is directly accessed in the code. This is a topic I briefly touched on in my 8 signs your code sucks post awhile back. I decided to return to this topic because it touches on a very important and fundamental programming practice which is limiting dependencies in code. This article represents the initial entry into a new series I plan on covering called "Java don't care." As aforementioned this series will focus on reducing dependencies in code, as well as making your code less aware of the environment it is in, and how following these practices will help you as a developer. But back to the task at hand; why referencing Java's http specification is bad.

The problems

A long list likely could be made as to why you should not directly reference http in your code. Here are four of the more important:

Testing

Probably the most readily noticable and debately the most important; referencing http in code greatly increases the difficultly of writing tests. To even begin writing a unit test you will need a tool to mock the http request/session. This increase in the difficulty of writing unit tests leads to two problems; decreased unit test coverage and increased unit test complexity.

Contract

A somewhat overlooked issue, but important none the less, is the lack of a contract between the view and the backend code that supports it. There is no central location to figure out what is contained in the request/session. The HttpServletRequest does not (and could not) provide this information. This lack of a contract can make it difficult to understand what is happening in the application as well as what the developer has access to.

Coupling

Directly accessing the http specification makes the code more aware of a view's internal implementations than it should be. The controller, and certainly the model, should not know the names of the various fields and variables in the view. It creates a mud ball of an application where changes to one level unduly necessitate changes to other levels.

You also introduce an unnecessary requirement into the application. Obviously requiring a web based application to include the httpservlet library in its classpath isn't particularly burdesom, but in other areas it could represent an issue. In general it is a bad programming practice to force requirements on an application.

Maintainability

Fundamentally this is more of a meta-issue, it is the inevitable outcome of the above three issues (as well as others). When you have an application that is difficult to write unit test for, hard to figure out what is accessible where, and has unnecessary requirements to work, you have an application that is difficult to maintain. I would argue that writing a maintainable application is the second most important requirement of an application (the first of course being one that it meets business requirements).

How to fix it

There are many differnet ways to fix and/or prevent this issue from occurring. Many frameworks, like Spring, (can) handle the session and request for you. This would also typically be the best way of addressing the issue. Let's assume, for the purpose of this article, that such an option is not available. Below is the controller of a simple application that I wrote that makes extensive use of the http request.

public class NewUserFormController extends HttpServlet {

@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
String nextPage = createUser(req);
req.getRequestDispatcher(nextPage).forward(req, resp);
}

private String createUser(HttpServletRequest req) {
List errorMsg = new ArrayList();
UserDao dao = new UserDaoImpl();
validateUserInput(req,
errorMsg);
if(!dao.doesUserExist(req, errorMsg)){
dao.insertUser(req, errorMsg);
}
if(errorMsg.isEmpty()){
return "Complete.jsp";
} else{
req.setAttribute("errorMsg", errorMsg);
setRequestAttributes(req);
return "Form.jsp";
}
}

private void setRequestAttributes(HttpServletRequest req) {
String fName = req.getParameter("fName");
String lName = req.getParameter("lName");
String eMail = req.getParameter("eMail");
req.setAttribute("fName", fName);
req.setAttribute("lName", lName);
req.setAttribute("eMail", eMail);
}

private void validateUserInput(HttpServletRequest req, List errorMsg) {
String fName = req.getParameter("fName");
String lName = req.getParameter("lName");
String eMail = req.getParameter("eMail");
String password = req.getParameter("password");
String confirmPassword = req.getParameter("confirmPassword");
if (isEmpty(fName)) {
errorMsg.add("Must enter a first name!");
}
if (isEmpty(lName)) {
errorMsg.add("Must enter a last mame!");
}
if (isEmpty(eMail)) {
errorMsg.add("Must enter an email address!");
}
if (isEmpty(password)) {
errorMsg.add("Must enter a password!");
}
if (isEmpty(confirmPassword)) {
errorMsg.add("Must confirm password!");
}
if(!password.equals(confirmPassword)){
errorMsg.add("Passwords must match!");
}
}

private boolean isEmpty(String string) {
return string == null || string.trim().equals("");
}
}

Entire source of the project can be viewed here

As you can see the access to the HttpServletRequest permeates near the entireity of the code base. As a result many of the issues I brought up are problems in this code (coincedence?). It would be difficult to write unit tests for this code, it's somewhat difficult to know what information is on the request, and I am dependant on the httpservlet in my code.

The fix

So clearly this code needs help. Our refacotring of the code has two major goals:
1. Create a contract between the view and the rest of the application
2. Reduce the depence on the http specification in the code

Typically in this situation I create a bean that holds all the fields in the request/session as well as a few additional meta fields (such as in this example the next page). This creates the previously mentioned contract. A developer can look at the bean class and know what fields are accessible in the application.

The usage of this bean will help accomplish goal number two. Instead of accessing the http request to get the data we need, instead I will dump all the data into the bean and access the bean and then reference it instead.

So here is what the new controller class looks like

public final class NewUserFormController {

private NewUserFormController(){

}

protected static String createUser(UserFormBean bean) {
UserDao dao = new UserDaoImpl();
validateUserInput(bean);
if(!dao.doesUserExist(bean)){
dao.insertUser(bean);
}
if(bean.getErrorMsg().isEmpty()){
return FormConstants.COMPLETE_PAGE;
} else{
return FormConstants.FORM_PAGE;
}
}

private static void validateUserInput(UserFormBean bean) {
if (isEmpty(bean.getfName())) {
bean.addErrorMsg("Must enter a first name!");
}
if (isEmpty(bean.getlName())) {
bean.addErrorMsg("Must enter a last mame!");
}
if (isEmpty(bean.geteMail())) {
bean.addErrorMsg("Must enter an email address!");
}
if (isEmpty(bean.getPassword())) {
bean.addErrorMsg("Must enter a password!");
}
if (isEmpty(bean.getConfirmPassword())) {
bean.addErrorMsg("Must confirm password!");
}
if(!bean.getPassword().equals(bean.getConfirmPassword())){
bean.addErrorMsg("Passwords must match!");
}
}

private static boolean isEmpty(String string) {
return string == null || string.trim().equals("");
}
}

As can be seen the HttpServlet dependency has been completely removed from this code. The code is a bit simpler as I removed pretty much all local variables and use the bean instead. However the best part is I can much more easily write unit tests (which I did).

So what does this mean to me?

Well these changes fix much of the four problems I mentioned above. However there is a couple other addtional benefits:

Increased modularity

If a new form was created that had a lot the same fields, but a few additional ones (say city and address), instead of writing a bunch of new code to handle this form, instead these classes; the bean and the controller (removing the final modifier) could be reused. The developer then only needs to write code and test for the new fields.

Separation of responsibilities

With a contract in place there is less of a requirement for the developer writing the backend to be involved in writing the view portion of the application (or vice versa). This allows developers (or designers) to better play to their respective strengths and makes parallel development easier.

You can view all the source code for the entire project here (revision 13 is the last revision relevant to this article). The project also requires the Java servlet package (2.3+)

Technorati Tags: Best practices, Java, Programming, Unit testing

Last week I published an article, An Intro into Test Driven Development with Junit4, which got somewhat mixed reviews. One particular commenter on reddit suggested I didn't understand that unit tests shouldn't talk to its data source. I decided to do some investigating into his claims, you can check out my findings here. I was however intrigued none the less and started looking for a tool that would allow me to easily mock a JDBC connection. I found Mockrunner to be the easiest to use of the ones I have found. Below is a brief tutorial on how to use Mockrunner. (Keep in mind that I am still fairly new to using Mockrunner)

In the class I am testing I am explicitly calling the columns I am retrieving by name. So I need to add these column names to my mock ResultSet.

result.addColumn("Date");
result.addColumn("High");
result.addColumn("Low");
result.addColumn("Condition");
result.addColumn("ID");

Obviously I also retrieve data from a result set so I must also insert data into the mock ResultSet. There are several ways to do this, but the easiest I found was using a list. You must add elements to the list in the same order as you added columns to the ResultSet.

List<Object> rowItems = new ArrayList<Object>();
rowItems.add(new Date(0));
rowItems.add(72);
rowItems.add(56);
rowItems.add("Cloudy");
rowItems.add(1);

In my actual test case I can verify that I am actually gathering the contents of the result set correctly and that the correct SQL statement was run.

prepareRS();
ForecastDAO dao = new ForecastDaoImpl(getConnection());
List<Forecast> forecasts = dao.getAllForecasts();

assertTrue(!forecasts.isEmpty());
verifySQLStatementExecuted("SELECT * FROM forecast");
assertEquals(73, forecasts.get(1).getHigh());

This is but scratching the surface of MockRunner's potential and using mocks at large. I hope this brief tutorial was helpful in getting you started using MockRunner. You can checkout the entire test class here and the class that I am testing here. If you want to get an entire working version of the project be sure to read the technical guide. Let me know if you have any questions or want to add your own comments.

Technorati Tags: Mock, Programming, Testing, Unit testing

Last week I published an article on test driven development. One person who read my article (briefly) suggested I did not know that unit tests shouldn't talk to their data source. I plan on covering how to mock JDBC connections later this week, however I wanted to do some research to see if what my critic says is an industry standard or a philosophical choice.

Surprisingly there seems to be relatively little information on this subject, or I have been incapable of finding information. From what I have gathered though, the theory that data sources should be mocked is sound, but its may not always be practical to implement it. Below is two reasons why data source connections should be mocked and three reasons why they should not.

Why you should mock connections

Speed – Talking to a data source is one the primary operations that slows an application's performance. Most data sources require some sort of network connection and retrieving data is often a processor intensive task. Obviously performing these tasks take time. Unit tests are most useful when they are run automatically and frequently to ensure changes being made are not breaking the application. Unit tests that are run automatically should be somewhat speedy, by mocking a data source connection, this can reduce considerably the amount of time it takes to run unit tests.

Remove the reliance on the data source logic – Unit tests should be testing relatively small parts of code, individual methods and/or small collections of methods. By connecting to a data source you are depending upon the logic of not only how you are connecting, but how the data source operates. This goes beyond the scope of what a unit test should be testing.

Why you shouldn't mock connections

It's time consuming – Writing mocks can be a quite laborious task. I often avoid writing mocks like the plague, because even relatively simple mocks can require a considerable amount of time to get running and running correctly. Even my very simple example of running a single query against a five column table took several hours to setup. Granted this was my first time creating a JDBC mock and future mocks would be easier and quicker to write, but it would still take longer than simply connecting to my database.

It's ugly – It takes a lot of typing to get even relatively simple mocks working. A lot of the rules that apply to how real business code should be written need not be followed when writing unit tests, that said looking at the code of a unit test shouldn't make your eyes bleed. Unit tests that cannot be easily maintained often become ignored when they break and broken unit test have no value (if ignored).

It's not real – Mocks don't really care what you put into or take out of them. Real data sources are often not so forgiving. If I misspelled a column or table name in a query, a mock would not pick up on this (you can verify the sql statements run, but again that could be misspelled), where as a real database would. By actually connecting to the real data source you can be more confident that the application will perform its intended tasks.

Why you should use your head

Even within the same project there will be instances where mocking a connection to a data source is the right choice and instances when you should actually connect to a real data source. In the early stages of a project using mocks can be more practical as the structure of the data source is more abstract and subject to change. Rewriting a mock is often quicker and easier than restructuring a data source. However as a project matures and the unit tests become more complex, connecting to the real data source may be more practical as it is not only (more) well defined, but writing the mocks begins to require more time. As with all practices, you need decide which one is best to follow (or not) based upon your requirements and restrictions. Though I think it is worth noting standards are standards for a reason. Feel free to weigh in with your own thoughts on the subject.

Additional reading:
http://www.javaranch.com/journal/2003/12/UnitTestingDatabaseCode.html
http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html

Technorati Tags: Best practices, Mock, Programming, Testing, Unit testing

Learning how to use the built-in IDE debuggers and write unit tests is as fundamental to being a developer as knowing how to write a for loop. These two tools will save you countless hours of frustration and help you write better code. Entire books are written on just these subjects, however today I will just give a simple tutorial on writing unit tests. In this example I will be testing a JavaBean that could be used in a simple inventory system. You can download the project here. If you need help setting up the project you can follow the instructions here.

package com.dining;

public class Item {
public String name;
public int id;

public Item(String name, String id) throws IllegalArgumentException{
if((name != null && !name.equalsIgnoreCase("")) && (id != null && !id.equalsIgnoreCase("") && id.matches("\\d*"))){
this.name = name;
this.id = Integer.parseInt(id);
} else {
throw new IllegalArgumentException("Invalid argument(s)");
}
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public int getId() {
return id;
}

public void setId(int id) {
this.id = id;
}
}

For my unit test I want to make sure my two argument constructor is working as expected. That is, it will require me to give a valid name, a String object with at least one character, and a valid id, a number. If either of these arguments are incorrect I will throw an IllegalArgumentException.

First we need to create a unit test class to run unit tests. To do this I will create a JUnit class, in Eclipse you can right click in your package explorer view and in the pop menu scroll down to the “JUnit” option, be sure to do this under the “com.unittest” package in the “test” folder. I will be using JUnit 3 for this example. The convention for naming for unit test classes is “Test” followed by the name of the class you will be testing, so in this case “TestItem.” The defaults should be fine so go ahead and click ok.

Each unit test case is its own method. Again the convention with unit tests is to start the name with “test” followed by the method under test. This is can be a looser practice as you might want to name the unit test based upon the type of test your are running. In this case I will name the unit test “testItemValidArguments” because I will be only passing valid arguments into the constructor. Inside the unit test you will make a call to the method you are testing and you will run an assertion to check to make sure the right value is being returned. There are numerous assertion types:

assetEquals(expected, actual) which compares what you are expecting to what is actually returned
assertTrue(condition) expects the passed condition to return true
assertFalse(condition) expects the passed condition to return false

There are a couple of other ways of running tests but these are the major ones. When these methods return an unexpected value; unequal values, false when true expected and vice versa, this causes the test to fail. If you are running your test in Eclipse the JUnit view will display red. Conversely if the test passes the JUnit view will display Green.

So lets write our first unit test:

public void testItemValidArguments() {
Item item = new Item("Wrench", "1");
assertEquals(2, item.getId());
}

No, I did not make a typo, go ahead and run the test an see what happens. Your test should fail (if it doesn't you have a problem). The JUnit view should look like this:

JUnit will let you know when you failed a test. In this case it's telling us that it was expecting “2” to be returned, but actually got “1.” Go ahead and change the expected value back to “1” and run the test again and it should pass. Ok so when we pass valid arguments the constructor works correctly. Now let's make sure the constructor lets us know when the arguments passed in are not valid. Let's write another units test:

public void testIteamInvalidArguments() {
Item item = new Item("Wrench", "A");
assertEquals(“A”, item.getId());
}

Try running the test. Your JUnit view should look like this:

Well good news bad news. The constructor validates the second field correctly, it is requiring a number, however we don't want our unit tests failing. All unit tests should “pass” when they run correctly so a change needs to be made. To cut to the chase this is one possible way of fixing the unit test:

public void testIteamInvalidArguments() {
try {
Item item = new Item("Wrench", "A");
fail("You should have thrown an exception!");
} catch (IllegalArgumentException e) {
//Do nothing
}
}

As long as a fail is not returned within a JUnit test case the test passes, so in the test case if the IllegalArgumentException is thrown then we won't do anything because we are expecting that, however if the exception is not thrown then we want the test to fail. So on the line below where I create an Item object I call fail() and pass in a message, so if the exception is not thrown the test will fail and I will know I have a problem (and a message will be displayed in the JUnit view).

I will end my tutorial here. This should be enough to get your feet wet in unit testing. There are several other tests that could be written, for example checking to make sure name validation works. I plan on covering this subject in more depth so check back later. This is my first real tutorial, so please let me know if I glossed over anything. If you have any other questions please let me know.

Technorati Tags: Best practices, Programming, Testing, Unit testing