In Let your examples flow, Dan North describes how “Don’t Repeat Yourself” (DRY) isn’t necessarily the most important guideline for tests. While I agree with his conclusions, I think the DRY principle is still extremely important for tests.
On my project, we use Maven to build our software and FitNesse to write functional specifications. However, it was obvious that FitNesse wasn’t designed by Maven-fans. When I use Maven, I already have control over my classpath, and specifying it in every FitNesse test gets to be old really fast. Why can’t I just inherit the project class path, and start FitNesse using maven-antrun-plugin or just from my IDE?
I found a neat way to implement this by overriding FitNesse. Using the same technique, I’m also able to debug FitNesse tests.
The code I write in Ruby is higher quality than the code I write in Java. Why? Because the language supports better abstractions. It lets me express a problem once, and reuse it many places. The strength of an environment comes from the quality of the libraries, and the qualities of the libraries comes from the features of the language. In this post, I will review a proposal to make Java a better language: First-Class Methods. See how much better the code looks with it.
My talk at JavaZone went surprisingly well. The fact that the projector went dead and that I was planning on opening with a demo raised my pulse, but I felt I managed to get my message across and that people were happy.
The talk was about how we use Jetty to manage the full deployment life cycle of our application. I explained how we had implemented this and what problems we had solved. Here’s a quick summary of our life cycle process:
Anders Nordås shows how to throw a checked exception without declaring a throws clause. The method uses some inherently evil mechanisms (the name of the class “sun.misc.Unsafe” should be a tip of), and like Anders says, this should probably never be used in production.
Java.net’s latest poll asks: should checked exceptions be removed from the Java language. Sadly, the poll is not going the way it should right now. Many people feel checked exceptions are key to reliable programming. They are wrong. Please: Read this post, and help improve the Java programming language by voting “Yes” to remove checked exceptions.
Checked exceptions is a concept that is unique to Java as a programming language. That is right: It was an experiment. I brave idea. It failed.
Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “requirement tests”. However, what unites the tests are more important than what divides them. The divisions are fuzzy, and they should be.
All tests have but two purposes: To tell you if you’ve completed a new requirement, and to ensure that you haven’t broken something that worked. There are three fundamental properties of a good test suite: Coverage, Robustness and Speed.
After spending more time than I care to indulge trying to get commercial application servers to behave, I finally decided to Do the Simplest Thing that Could Possibly Work, and create a new application server from scratch. Well, not really a full application server. For 90 % of the Java applications out there, all that you really need is Servlets, so I limit myself to that. And not really from scratch. The servlet functionality is provided by jetty, the application is built using Maven, the startup script is generated with the Maven Appassembler Plugin, and the final package is constructed using Maven Assembly Plugin.
The result is a project that lets me construct and release zip-files that can be copied onto an server host, extracted, and started up with a single script. With some help from my friends, I’ve added a few bells and whistles to make it as complete as possible. However, this article describes the simplest possible “Maven application server” that you can start with. You can find the application code in my subversion repository.
Last night, I worked until after midnight trying to get our application up and running after some seemingly inconsequential changes in Spring-XML configuration. Our application consists of a total of 32 modules (including 6 wars and one “server” module that packages them, and 11 modules that are shared with other projects). Most of these modules have Spring-XML fragments that are included in a few different ways, with the result that a nobody on the team actually understands how it fits together. My conclusion is that Spring-XML is at least as bad as the old ejb-jar.xml and similar regimes that is has tried to replace, and that it might be a sufficient reason to recommend not using Spring at all.
Inspired by Per Mellqvist (and myself, to be fair), I wanted to explore the possibility of using a generic DAO or Repository interface for REST. Based on this simple idea, I was able to create a very cute and testable prototype of a full Web Service stack for REST based Web Services. The most interesting aspect was creating a universal test case for Repositories.
This article shows how little code is required to implement and test a REST based Web Service in Java, despite the horror of the Java HTTP client API. The source code can be downloaded from my subversion repository. I also want to illustrate how to create black box tests that can be reused efficiently with different implementations of a Repository.
Subscribe (atom)