The JWalk Weblog

We are pleased to announce the availability of the JWalk 1.1 tool suite, the multi-threaded version of the JWalk lazy systematic unit testing toolkit. This includes two finished tools: JWalkTester is the flagship tool, a GUI-based Java class unit tester, which is also the default tool launched in the bundle. Alternatively, JWalkUtility is the original command-line utility, which executes in a standard console window, interacting with the user on standard input and printing results to standard output. The download bundle also includes the complete JWalk Toolkit for building your own JWalk testing applications around the core test engine. Built using run-anywhere Java, the tools configure themselves to the host's operating system, whether Windows (see the featured JWalkTester running on Windows 7), Mackintosh, Unix or Linux.

The tools support the revolutionary lazy systematic unit testing method, in which specifications are learned incrementally from prototype code; and from these, systematic test-sets are generated to validate the production code. The method is particularly suited to agile software development methods, such as eXtreme Programming, which have a strong emphasis on software testing, but no time to provide specifications. So, where do the unit tests come from? With the JWalk 1.1 tool suite, you can continually update the test oracle for each prototype Java class, by exercising the class inside the tools, and responding to queries about particular test outcomes. The tools use strong state-based and algebra-based test generation algorithms to ensure that the Java class is thoroughly tested, up to the current inferred specification.

Wednesday, 9 January 2013

I have been looking into the cross-package importing issue reported by Michael Keene (see the blog for November 12, 2012). This was to do with cross-package importing from within particular development environments, such as Netbeans or Eclipse. I'm still hoping Michael will supply a canonical fault example, as I have so far been unable to replicate the fault.

Here's what I know JWalk can do with cross-package importing. JWalk expects to be run in the root of any collection of package structures (the "location" is this place). The test class "name" must then be specified using its fully-qualified package name. In principle, the class loader will access other packages from the same root location, expecting the corresponding directory structures underneath.

It is also possible to test classes that are "outside" this root location, if you specify a standard location known to the Java CLASSPATH that is interpreted by the class loader as a "new location", for example, you can test java.lang.String by specifying that fully-qualified name, no matter where the JWalk tool is running. However, Michael's reported issue is failure to recognise other package locations when these are managed by Netbeans or Eclipse environments. I know that Netbeans and Eclipse sometimes ignore the CLASSPATH and use their own build-paths for compiling, and also use special versions of the standard Java compiler.

Monday, 7 January 2013

Happy New Year to all our JWalkers! I'm back to work today, with a mission to mark a shed-load of student assignments and then get back to software testing research again. Wish me luck, as this is the toughest part of the year!

Back to earlier entries...