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

In my recent article, 8 signs your code sucks, one of my signs of bad code is: “You need to use comments to explain the code.” I have since taken a lot of flak for suggesting this and I want to clarify my point and why I am not backing down.

Not javadoc - I am NOT referring to Javadoc or its equivalents in other languages. I absolutely do agree that a method or class should have accompanying documentation at its declaration stating its purpose and its inputs and/or outputs.

Comments are not bad, the code is – I'm not suggesting to forgo the use of comments, but that they are only band-aids. When you don't have time to properly write a piece of code; do it the “messy” way, write a comment and give it a TODO as a reminder to go back and fix it later.

Comments make code accessible - Code should not be written to the level of the dumbest developer, the dumbest developer should be brought to the level of the code (though I want to reiterate good code should be easily readable). If a developer is unwilling or unable to meet or at least understand the rest of the team's coding standards, then questions should be asked rather you want that developer to understand the code at all.

They are more like guidelines – When it comes to design patterns there are no rules. From day one we are taught goto statements are evil and should never be used, but there is even a time and place for them. There may be rare occasions when you have to write a comment to explain a piece of code, just like you may need to use a goto to simplify the code, but both occasions are rare and when encountered in code should be scrutinized.

Technorati Tags: Best practices, Programming

As a wide eyed junior developer when I first began working on large projects I simply accepted that it is difficult to fix bugs or find where an action is being executed. If only I knew then what I know now, I would had saved myself hours of frustration. The first step to writing good code is accepting the code you write (or work on) is crap, but sometimes you need to know what to look for. Here are some signs that your code sucks.

A method is larger than the screen – A method should only perform one specific task. A method should not contain the logic code to determine if the username field contains data, is valid, and that user exists. If a method is too large to fit within a single screen, that is a (very) good sign it is doing too much.

You are reusing variables – Unless you are working on embedded devices, memory is cheap. Don't be a memory scrooge and knee cap code maintainability, which in nearly all instances trumps performance, by reusing the same variable for multiple uses.

You are directly accessing the request/session – It not only makes writing unit tests (much) harder, but it is also difficult to know what data the application has access to. All data should be taken out of the session/request and stored in a bean. A bean, through its getters and setters, creates a “contract” of what data the application has access to, which greatly helps with code maintainability.

You need to use comments to explain the code – Code should be able to explain itself and should be in a format that is easily readable. If you find yourself needing to explain what your code is doing then you may want to look into rewriting that code.
EDIT: This is not referring to using comments (e.g. javadoc) to explain the purpose of a method/class and its inputs and outputs.

An exception's stack trace doesn't return the original problem -  You should never “eat” an exception, that is catch an exception, but not print its stack trace. How can a bug be fixed if you don't even know where the bug is occurring?

Your code is a mud ball – Just the name sounds ugly. A “mud ball” is when there is little separation between the layers or concerns of an application. Code should be modular allowing for ease of reusability and modifiability. Anything concerning the user interface happens in the view, program flow and usually data validation is the domain of the controller, handling business logic is the model's job, and only the model should be interacting with the data access layer.

It is hard to write a unit test – If you find a bug or write a new piece of code and it takes you more than a few minutes to write a unit test then that portion of code is handling too complex of a task.

The author is Billy Korando – Wait what?!

Add your own experiences or signs for dealing with sucky code.

UPDATE: There are differing opinions on my signs, since I am but a mere "grasshopper" I maybe wrong. Anyways check it out and make up your own mind.

Technorati Tags: Best practices, Programming

Integrated development environments make developing application fair easier. They highlight syntax, let you know if you have a compilation error, and allow you to step through your code among so many other things. Like all IDEs Eclipse has a bunch of little shortcuts and tools that can make your life a lot easier, I've compiled a list of several that I use on a daily basis:

1. Auto-complete – Eclipse has an auto-complete feature that can be accessed with ctrl + space. When clicked a small pop-up box is displayed with a list of context sensitive suggestions. If there is only one possibility then Eclipse completes it for you.

2. Quickly format your code – Code that is being heavily modified can quickly become an ugly sight. Without proper indention it can become extremely difficult to determine what is happening in code. Code can be quickly formatted using the shortcut: Ctrl + shift + F. You can even setup your own style rules by going to: Project>Preferences>Java Code Style>Formatter, check “enable project specific settings” edit the profile and then save it under a new name.

3. Get rid of unnecessary code – Heavily worked on projects that aren't maintained well can quickly build up a bunch of unnecessary imports, casts, among other common easily detectable coding mistakes. Quickly remove these mistakes by running a code clean up. Right click on your project folder>source>clean up. Like the code formatter you can also customize your code clean up.

4. Go to declaration – Want to know where that method, variable, or class is declared? This can easily be done by holding down ctrl and then clicking on the reference.

5. Find all references – If you need to find all the references for a method, variable, or class highlight the desired reference right click>reference and select the desired search scope.

6. Quickly select groups of characters – Need to delete an entire string, or everything within a method's argument declaration? Select the enclosing character (e.g. the “ or "(" respectively), this will select everything within the enclosing characters. This even works with the bodies of classes and methods. You can also select an entire line by triple clicking.

7. Rename all instances – If you need to rename a method, variable, or class you can rename ever instance by highlighting a reference and pressing alt + shift + r an box will highlight the reference and you can rename it. Upon pressing enter all instance will be renamed in your project.

8. Change a method signature – If you need to change any part of a methods signature; a methods name, its arguments, or return type, you can quickly make a change to all references of the method in the project by highlighting the method and pressing alt + shift + c a pop-up box will appear giving you options to change the method's signature.

9. Automatically generate getters and setters – Writing getters and setters is for suckers. After you write out all the members of a class right click anywhere in the code screen>source>generate getters and setters. Select the variables you want to have getters and setters made for.

10. Javadoc is a cinch – Eclipse makes writing Javadoc easy, just type “/**” and press eneter above a declaration. Eclipse automatically creates context sensitive Javadoc annotations (i.e. a methods parameters, or the author of a class). After that you only have to write out what the method actually does.

11. Run a unit test – To run a unit test highlight the unit test and press alt + shift + x followed by t. You can also run a unit test in the debugger by pressing alt + shift + d followed by t.

12. Comment out code – If you need to quickly comment out a chunk of code, highlight the corresponding lines and press ctrl + /, you can uncomment code the say way.

Chime in with your own Eclipse shortcuts.

Technorati Tags: Programming

If you like what I have to say, share it with others by using the "Share" button at the bottom of every post. This button includes links to all the popular social sites. Help get Turnleaf Design out the masses by submitting an article or up voting already submitted articles. Your help is much appreciated, thanks!

With the publication of the first part of my SVN primer I will begin two major series on my site that will occasionally intermingled. My first series is what I like to refer as “The Promised Land.” This project will cover how to setup up an ideal development environment. Subjects will include version control, Ant (build scripts), Ivy (dependency manager), software configuration management (SCM), automated unit testing, and bug tracking. I may add a few subjects as requested or if I find anything else I think might be relevant and interesting. The series is name “The Promised Land” because hopefully by following the advice in the articles a development team can focus only on developing and maintain its applications and not have to worry about any other hassles. I will put all the "Promised Land" articles under the "Promised Land" category.

The second series and one which I am becoming increasingly excited about is developing a project that will track the accuracy of weather forecasting (I mean it always seems like meteorologist are just guessing). Ok that alone may not sound interesting, but what I plan on doing is using this project as an example for many other important topics. Sometimes it is difficult to understand the usefulness of design principle or a tool without seeing it within the context of an actual project, I plan on addressing this short falling. I already have a huge subject plan lined up:

Design methodology/Best practices

MVC
Data access Layer
Framework - Spring
Separating layers; best practices
Methodizing
Usage of static
Interface/implementation
Generics - explanation
Exception vs error handling
where to validate

Development environment

Hudson
Ant
Ivy

Unit Testing

Test driven design & more advanced JUnit tutorial
DBUnit
JMock
Automated Unit testing

Other

XML
JSON
JSPs
Webservices
How to consume Soap/WSDS
How to create REST/WADL
IDE tips

As I get closer to launching this project, which should be next week, I will give more details on how it will work.

I'm really excited about both of these projects and I think both will be very helpful to both new and more experienced developers alike. If you have any questions let me know in the comments section.

Sometimes developers use programming jargon that new developers have a hard time comprehending. One term I frequently hear is “bean.” All a JavaBean is, is a class used to define the attributes of a entity; examples of commonly used beans would be person, customer, and employee. A JavaBean typically only contain private attributes and the getter and setter methods to access and set those attributes respectively. Here is a simple example of what a Java bean looks like:

public class Employee {
private String firstName;
private String lastName;
private int yearsExp;
private String title;
private double salary;

public String getFirstName() {
return firstName;
}

public void setFirstName(String firstName) {
this.firstName = firstName;
}

public String getLastName() {
return lastName;
}

public void setLastName(String lastName) {
this.lastName = lastName;
}

public int getYearsExp() {
return yearsExp;
}

public void setYearsExp(int yearsExp) {
this.yearsExp = yearsExp;
}

public String getTitle() {
return title;
}

public void setTitle(String title) {
this.title = title;
}

public double getSalary() {
return salary;
}

public void setSalary(double salary) {
this.salary = salary;
}
}

JavaBeans are also commonly referred to as POJOs (Plain old Java objects). The terms are not entirely synonymous, as a POJO refers to a specific type of class, but is none the less often used interchangeably.

Tip: Most IDEs can automatically generate the getter and setter methods for a class' attributes, so don't waste your precious time doing it! In Eclipse just right click any where on the code screen select source>generate getters and setters, and follow the instructions. Simple as pie!