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
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
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
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...