Test Driven Development — How to start with a test

Test driven development is mystical to anyone that hasn’t done it from the ground-up. It’s almost like riding a bike; you really don’t know how easy it is and how much fun you can have with it until you get up and going. When the training wheels are off, it then becomes a brand new world full of possibilities.

I have been writing unit tests for years. Having come to the Java game later than most of my colleagues, I really like to make sure that everything I commit to my various development communities are well-tested and as clean as I can make them. Unit testing has allowed me to verify this in two different ways. First, it guarantees that what I’ve writting works, and more importantly, it makes me keep my code simple. Frankly, if I start writing a test and it becomes a dependency-driven, closely-coupled to the implementation monster, I can pretty much guarantee that the code is going to be the same. I’ll try to refactor this and use my tests in this manner as a guage for it’s quality.

Struts vs. Cocoon: Why Cocoon lost the battle.

Cocoon has been around for years with an active development community. I tried to work with it in 2002 using the books and resources available at the time, but I was using Windows at that point and the books really focused more on a Unix/Linux deployment, and at the time I didn’t have the chops to really transfer this knowledge cleanly and was really never able to set up a coherent development environment for it. Struts, on the other hand, had the resources available to get up and running. Although the documentation wasn’t that great, I could “get home” on most issues, and when the level of frustration on completing some of the things that I needed to get done was at a boiling point, I did something about it and wrote a book with George Franciscus to share what I had learned with the larger community. I wasn’t alone with this either; many great books on the subject came out. As the framework diversified and solved many problems, so did the available web and print documentation from many wonderful people.

Step forward to today. Struts 1 is ubiquitous; nearly every Java Web Application Programmer has had some experience with Struts, building upon the base and working to create other Frameworks as well extend Struts1 into Struts2. Lately, I’ve been working with projects that consume a great deal of XML services and need to be available to many different viewing platforms in a coherent manner. Not only that, but there is a tremendous amount of conditional logic that must be matched depending upon input. Cocoon handles these things very well — it’s dispatch system allows for various URL matching which gives it’s configurations a very similar feel to a lightweight Business Rule engine. I decided to give it another shot and go through the tutorials and documentation — trying to evaluate whether or not it could fit into the way that my company does business.

I proceeded to find tutorials on the Cocoon Site, DeveloperWorks and other places. What I found was at best adequate, but at worst quite disappointing. The Cocoon Community insists that you download their source code and use their scripts to

Creating a Java TesterTimer for Performance Testing.

I often find myself writing lightweight performance tests as part of a suite of the unit tests, to make sure that my code hasn’t been written in a way to destroy the performance of an application. I also create performance tests as a standalone Application to test (for instance) how many HttpServletRequest/Response calls can be made over a certain period of time.

My requirements are normally simple, and rarely have a strong need to be COMPLETELY perfect; i.e. the actual calls to and from the timer can cause a slight time loss in the actual application, but frankly I’m willing to put up with this in most circumstances. The “TesterTimer” class featured below is pretty damned efficient, especially if you never call the “elapsed(id)” method, since the start and stop happen pretty much outside the application being tested. Here is the fully commented code with a demonstration “main” class:

Adding a DRL FileType with Syntax Highlighting to IntelliJ

IntelliJ’s support of JBoss-rules in no way compares to Eclipse, but even that isn’t enough to get me off my butt and move from my fave. That said, I created a semi-literate FileType for the drl files so that IntelliJ will recognize them and you will get a decent amount of syntax highlighting. Is it perfect?

No.

But it will probably get you home. Here’s what you do. Create a new filetype and make sure that it includes ?*.drl files. Once that is created, it makes a filetype with the name you gave it in the

%User%/Library/Preferences/IntellijIDEA%your-release-version-here%/filetypes/%name_of_file.xml%

directory (at least that’s what it looks like on my Mac – I haven’t touched a windows box in years, but it should have some parallels.

Open the XML file and replace anything between the <filetype> nodes with: