Long since I read Mike Clark's lava lamp set up with CruiseControl, I haven't tried it because there was no proper USB-to-Serial adapter for Mac according to Mike.

When I exchanged the idea with Jon, the project’s development team leader, who was so enthusiastic that he went to eBay and ordered the kit straight way. The setup wasn't hard, but no without issues (CruiseControl's x10 integration worked with x10 module we got with strange exceptions). Anyway, the outcome was great, it exceeded what I could hope for.

Now when a build is broken, developers will work on the cause without reminding. When I enter the office, my eyes now are naturally drawn to those lava lamps first.

Update: Here is the article on how I set up build lava lamps for a Java Project.

Tags: Work, Testing, Build Server

I have been working with Ruby and .NET mostly for last 1.5 years. I spent last weekend to pick up my Java, it wasn’t hard, worked with Java for about 8 years after all. I re-created the lightweight java framework with latest version of goodies: Spring, Hibernate, Struts, HSQLDB, Jetty.

The zip file is quite big: 12M, that’s because it includes all the libraries: Spring, Hibernate, Struts, HSQLDB, Jetty, ..., etc. The build script (Ant) generates a WAR file, which can be deployed into any J2EE containers with a little vendor-specific configuration. Yes, the build script also generates unit test and code coverage report.

A few notes on testing:

• Can unit test the view because of using Velocity
• Unit test Database access layer Hibernate + HSQLDB, very cool! (Thanks Jon Tirsen)
• A single StrutsTestCase (with Spring aware) for unit testing Struts actions
• Use JWebUnit for functional testing, will move to rWebUnit

The sample application is a online video store, my pet project. I removed the original web framework WebWork, as it is going to be merged to Struts2 anyway. The application logic is left empty at the moment.

Here is the release notes:

1. Unzip the lightweight_java*.zip to a folder
2. Double click the ‘run.bat’ under the folder (Unix/Mac guys, I am sure you know what to do)
3. Open your browser, enter url: http://localhost:8080/videostore

Download Zip file

Screenshots:
1. Start the server in IDE (Intellij IDEA) < 5 seconds:

2. Access the home page in a web browser:

Tags: Lightweight , Java

Days ago, I was planning a demo of one Rails application to a potential client. I could bring and show it on my MacBook Pro, but it might leave the client thinking “this might not work well on Windows”. So I came up with a solution: Plug in a thumb drive, double click a shortcut, application runs on client’s Dell laptop, and here it is.

portable_ror-1.zip (9Mb)

What’s in it?

• Ruby 1.8.5 for Windows (thanks for One Click Windows Installer)
• Sqlite 3.3.7 (under ruby/bin)
• Gems: Rails, Mongrels, RSpec, Watir, ... (To minimize the file size, I removed all docs).

To Install/update a new gem
G: \ruby\bin\gem.bat install --no-rdoc --no-ri your.gem
(I didn’t want to install rdoc stuff, as it takes space and time)

Install a rails application
Assume your thumb drive was assigned as "G:", you shall see the folder

G:\ruby\gems\railsapps

Just unzip your cool rails app there.

To start a rails application

cd G:
chdir \railsapps\rvideostore
\ruby\bin\mongrel_rails start --environment development --port 5000 --log log\mongrel.log --pid log\mongrel.pid

This is the kind of thing that is not difficult to do, but may get ‘WOW’ effect.

Tags: ruby

In my opinion, the most difficult part of automated user acceptance testing is maintaining the tests rather than writing them (We are talking about serious automated testing here, hundreds or more runing every day).

My rules of user acceptance testing

• Customers shall understand the test scripts easily.
• Each line of test script shall match (or at least very very closely) one step of operation as if the test is executed manually
• A test case can be executed individually or as a part of suite or all.
• If a test fails, the console output show error/failure stack trace, including the line number
• After the test is run whether success or failure, it shall not affect other tests’ result (it is quite hard)
• If a test fails, the system is left with the state the tester can check manually.

Preferably

• Users/Customers write the test scripts (It’s actually much easier than it sounds, :-)), developers write helper tier undereath the tests. For example,

// In test script (java):
assertEquals(getTransactionDate(), today())

// In test helper (parent class):
protected String getTransactionDate() {
// retrieve the transaction date on the screen
}
protected String today() {
// return today in defined format
}

• The tests are run everyday (obviously), and with (funky) test report
• The test case name clearly indicates its intention, such as test_guest_cannot_access_member_area_redirect_to_login
• The testing framework is in some kind of scripting language (no compiling), they are ‘test scripts’ after all.
• Only one configuration parameter: env. For example, to test staging environment, just pass the -env=staging in execution parameter

A common mistake: It is easy for developers to put her in dominant position of choosing the framework and writing automated functional tests ; Sadly it is even easier for customers/testers to accept that.

Tags: functional testing