Tuesday, November 14, 2006

WSAD and Maven - playing together

Ok, from what I could determine the latest (and now no longer supported IBM's WSAD) is akin to a 2.1.3 Eclipse build (just for those people still tied to this IDE). To integrate Maven with WSAD, follow these steps:

WSAD (requires a project to have a Maven project file, ie. project.xml)

  • Select Window / Preferences
  • Select Java -> Classpath Variables
  • Select 'New'; type MAVEN_REPO for name; and location of the Maven repository for path (specific to the view of each developer)
  • Go to the project's location; checkout the .classpath and .project files type maven eclipse (this will generate the accurate classpaths according to the Maven project.xml descriptor).
  • 'Refresh' your project space; you will notice that under Properties -> Java Build Path that all libraries have been updated with the Maven repository (and not hardcoded)
No more hardcoded libraries and one can check in the .classpath, and .project files for a seamless, defined, development environment.

Wednesday, November 01, 2006

Writing tests in development

I recall on a number of previous projects that there was always some confusion around the type of tests that were written in development; that is, unit tests, integration tests, component tests, system tests, etc.. Of interest, then, I recently read this article from IBM developer works (a truly interesting RSS feed for those in Java software engineering).

Basically, it states that tests need to be categorised into:

  1. unit tests: single-class driven tests; isolating a piece of functionality (hopefully only one public interface per class!)
  2. component tests: multiple-class driven tests; often including core pieces of logic and functionality
  3. system tests: end-to-end testing; high-level, arbitrary logic executed; does the application work?
Importantly, it defines that the time taken for each category will increase significantly and therefore there should be multiple build / test loops with their own individual reports. So the unit testing which is used everyday is not corrupted by the component testing (e.g. driven by test defects) or system testing (e.g. driven by releases).