Build Tools

ANT and Maven were mentioned, but not Rake. That put me off a bit, because I happen to love Rake. This was a Java talk, but even so, plenty of folks are using Rake for Java builds.

So Rake is a clear winner for me over Ant and Make. But I confess that I had no clear idea understanding of Maven's capabilities prior to this talk.

Maven 2 is a pluggable build framework, with many plugins. It also lets you do some scripting when scripting, but your build configuration is mostly declarative. And it chants the "convention over configuration" mantra that makes Ruby on Rails powerful without being painful.

Maven 2 also allows for declarative dependency management, which solves the problem of JAR files that contain different versions of the classes you need.

Ivy solves that problem for ANT, meanwhile. And there are Maven tasks that do the same thing--which suggests to me that running Rake in JRuby makes sense, in order to take advantage of the Maven tasks, and other tasks built for ANT.

Note: Fellow attendee Steve Davidson mentioned that Hibernate and most of the Apache projects use Maven, and they love it.

Automated Testing

For testing, John mentioned JUnit 4.4 and TestNG, but only went into detail on JUnit. (Ruby's RSpec wasn't mentioned, but it was interesting to see Java's unit test harnesses moving in that direction.)

With JUnit 4.4, any class can contain tests, which makes it easier to do behavioral testing, because your test classes no longer have to match up with applciation classes. The tests can also contain annotations like @before and @after for setup and teardown code.

JUnit 4.4 also allows for timeouts, tests to make sure the right exceptions are thrown, and parameterized tests.

One of it's more interesting features is "Hamcrest asserts". Those asserts read more English, so instead of seeing:

assertEquals(x, calulated(y));

You get:

assertThat(calculated(y), is(expectedValue));

Or:

assertThat(color, is("blue");
assertThat(color, Not(isIn(colors))));

You also get more readable error messages:

"Expected "blue", got "red"

That's all a vast improvment, but it's still nowhere near as readable as RSpec--a Ruby-based vehicle for unit testing that was designed from the ground up for behavioral testing, and which takes advantage of Ruby's language-constructing capabilities to create tests that are truly readable, but they're all steps in the right direction.

Note: Another tip from Steve Davidson: For database testing, he uses HSQLDB--a standards-compliant database with a version that runs totally in memory, for lightning fast testing. (To be sure he testing against the latest schema, he runs the setup scripts the Q/A team is using.)

Finally, for test coverage, developers will want to take advantage of IDE-level tools to guage the effectiveness of tests for the code they're writing, and the team as a whole will want a project-wide coverage tool that provides useful reports.

For IDE tests, there is the tool built into NetBeans, the EclEmma plugin for Eclipse, and an experimental Crap4j tool. For project-wide coverage, there is Cobertura.

(On a related front, there are test frameworks like Selenium and HtmlUnit for Web apps.)

Continuous Integration

If you don't have automated testing, continuuous integration doesn't help you much. And if you don't have automated builds, it's not possible. But if you have both, and you're using any kind of source control system (cvs, subversion, etc.) then continuuous integration is the next most important step you can take to ensure success.

Note: StarTeam was also mentioned for source control. That could be worth a look.

With continuuous integration, you identify integration issues sooner, rather than later. Like unit testing, it lets you find bugs closer to when you created them, which makes them easier to diagnose. It also means that, two weeks before you're supposed to ship, you don't suddenly discover significant problems that require a massive design change.

Continuous integration allows lets you do frequent releases, which is important for any kind of agile development cycle.

To do it, you need a continuous build tool. Open source systems include CruiseControl, Hudson, Continuum, and LuntBuild. There are also commercial systems like TeamCity, Bamboo, and Pulse, but according to Smart, the open source tools do pretty much what you need (as of today, anyway).

Automated Code Checks

Automated checking of source codes helps to ensure quality, but if nothing else it ensures consistency, which improves maintainability -- and maintenance can be as much of 90% of the cost of any sustained application effort. (And with automated checks, developers train themselves!)

Tools for automated code checks include:

• Checkstyle (for naming conventions, formatting)
• PMD (helps to ensure best practices)
• findBugs (identifies potential bugs, e.g null ptr exceptions)
• crap4j (an experimental tool that finds overly complex and untested classes, when it is used for unit-testing)

Automated Documentation

You still need to put together high-level architecture docs, but these tools let you generate details automatically:

• JavaDoc (for APis)
• UmlGraph (for class hierarchy)
• SchemaSpy (for a graphic rendition of the database model)

Missing from the list was object interaction diagrams--A UML model that tend to vastly more informative than class hierarchy diagrams for understanding how a system works but which, like high level architecture docs, need to be created with a selective focus and high-level understanding.