Why and how of test first development

Test-first development is the process of writing your test code before your implementation code. I have always felt this was the ideal approach but NOT necessarily the pragmatic approach to development. The thought of writing a full test before writing the code was essentially writing the specifications first and feels almost like a micro-waterfall approach to development.

I attended a couple of talks recently that made me realize that test-first is not necessarily about writing the entire test case before the implementation. Rather, you can take a very iterative approach. The idea is that you write just enough of the test code to get your implementation code to fail followed by just enough implementation code to get it to pass. Then you write just enough test code to get your implementation code to fail again and repeat the process until your test and implementation code is complete.

To be more specific, the first line of test code could simply be calling a method that does not exist in your implementation. This will cause a compile error (for those of us on stronger typed languages). Then you write just enough code to get the compile error to go away. Some of you may be thinking that compiling is not unit testing which is true but it is a form of testing nevertheless.

The second line of test code could simply be an assertion that the returned object is not null. This should result in a test failure. To pass this test, you can simply return a dummy object. Now obviously your implementation code should not be returning dummy objects. So, the third line of test code could compared the return value with an expected value which should cause the test to fail since it was initially returning a dummy value. Then at this point you would modify the implementation method to return the appropriate value dummy object.

Note that this approach breaks up your test into finer grain assertions. Had you write the test first, you would probably have never thought about performing an assertNull which would aid in debugging. In more complex methods, there would probably be many forgotten assertions. This finer grain approach also makes the test easier to write since we are taking a small bite at a time.

I have been using this approach for the last few months and this has actually become my preferred means of development. In fact, I now get that dirty feeling when I write tests after implementation, much in the same way a test-infected person feels dirty pushing code without unit tests.

Rolling your own security authentication/authorization?

Before you do, watch this 50 minute video on Spring Security:

http://www.viddler.com/explore/oredev/videos/22

Make sure your implementation of security rolling matches the ease of implementation and features of Spring Security. If not, use Spring Security.

Database Connection Pooling: c3p0 versus dbcp

I was looking at database connection pooling the other day and was trying to decide between c3p0 and Apache Common's dbcp. Both are open source (of course) and implement the standard DataSource interface, which means that you can pretty much swap out one for the other without breaking functionality. Both are not very up-to-date with their last stable releases being over two years ago: The last stable release of dbcp (1.2.2) was 2007-04-04 while for c3p0 (0.9.1.2) was 2007-5-21. The consensus appears to say that dbcp is better for single threaded applications while c3p0 is better on multi-threaded applications (which would include your webapp). Based on this alone, I favor c3p0.

Reference:
Spring Forum posting
Javatech comparison of c3p0 versus dbcp
Stack Overflow discussion

Spring versus Hibernate Validator

I looked at both Hibernate and Spring Validation briefly today.

Hibernate is annotation-based and works something like this: (1) You annotate with the proper validation rule (e.g., @NotNull) on the fields of your bean; (2) You call Hibernate's ClassValidator to validate, which returns the validation errors. Presumably, it inspects the annotations on the bean fields and performs the appropriate validation.

Pros: Easy declaration based validation.
Cons: I haven't figure out a way to perform database check for uniqueness.

Spring's validation is programatically-based. You implement the Validator interface which contains two methods, one of which is the validate method. You perform your validation manually, either writing the rules yourself or using Spring's utility methods, e.g., ValidationUtils.rejectIfEmpty(...)

Pros: Very flexible which allows for database record-based validation
Cons: More complex than Hibernate's Validator.

Neither solution is particularly ideal. Hibernate seems too simplistic while Spring's requires too much programming. I lean towards Spring's Validator mainly because it's very apparent as to how one would perform database record validation.

Reference:
Tutorial: Getting Started with Hibernate Validator
[Chapter] 6.2 Validation using Spring's Validator interface

Groovy over Java

Dynamic languages, once relegated to hobbyist and small mom-pop development shops, now (as in the last 2-3 years) seem to be the latest fad in "enterprise" development shops. I think this was largely due to the success of Ruby on Rails and Python which showed that you can write maintainable large scale software using dynamic languages.

Groovy appears to be the Java community's answer to dynamic languages. Groovy is a superset of Java which means that your existing Java code should mostly work in a Groovy interpreter. Groovy provides many of the syntactic sugar that you see in dynamic languages such as key-value dictionaries (hash tables), named parameters, closure, and etc.. Groovy has been submitted to Java Community Process program for standardization.

I'm still a bit mixed about using dynamic languages because I like the security of compile-time type checking. However, I do see myself using Groovy to write my unit tests since the syntactic sugar can potentially make my unit tests easier and faster to write.

Spring MVC

Here is a nice link describing the features of Spring MVC:

http://www.infoq.com/articles/spring-2.5-ii-spring-mvc

The information may be outdated with Spring 3.0 just around the corner.

One of things I like about the Spring Framework in general is that it's not very intrusive. Depending on your requirements, you can use the Spring Framework without: extending any class, implementing any interface; nor writing any adapter classes. This makes the framework extremely flexible because you are not locked into their application programming interface (API). If you're reading this blog, then you probably know that using open source frameworks is a way to avoid vendor lock-in. However, using open source alone is not enough to prevent vendor lock-in. We also have to think about API lock-in. The more your framework requires implementing/extending framework specific interfaces/classes, the more at-risk you are to API lock-in.

The Spring Framework also has a la carte style approach of integration into your existing software components. You use what you need and can add the incrementally framework as you evolve as a developer. In my current project, I started off using Spring's mock (stub) objects for testing (instead of writing my own MockHttpServletRequest). Then I used Spring's Object/XML Mapping (OXM) framework to domain convert objects to XML and vice versa. Now I'm looking to use Spring's MVC framework and eventually move all my object configuration and construction using Spring's core bean container.

Failed Searches

I'm lazy. Very lazy. I don't like keyword searches that do not return what I want on the first page. I don't like it because I have to make extra mouse clicks to find what I want. And I don't like extra mouse clicks because I'm lazy.

I'm sure I'm not alone. As obvious as this may seem, many commerce websites don't get it. They develop interfaces that make me perform unnecessary mouse clicks. They make me turn pages. If I have to turn to the next page of a results set, then your search has failed. Your search should have return the relevant results on the first page. Many sites also make me sort my search results. If I have to waste mouse clicks to sort my results, then your search has failed. Your search should have returned in the order of most relevant results. Some sites have even gone as far as making me filter my results set. If I have to filter the results set, then your search has failed. Your search should have returned only filtered results.

This all may seem a bit harsh. The point, however, is not to set unrealistically high criteria of what constitutes a good search engine. Rather, I'm suggesting that as developers we need to value mouse clicks. Every mouse click is precious and should not be wasted on paging, sorting, and filtering -- none of which would be needed if the search was done right in the first place. In the end, paging, sorting, and filtering are all crutches for broken searches.