Written in Perl, WebInject is primarily a command-line tool, though its author provides a thin Perl/Tk user interface that at least simplifies the execution of tests for those unwilling to spend too much time at the command prompt. If you're not familiar with Perl, don't panic. WebInject is built so that you can construct your tests without having to touch so much as a byte of Perl code.

Click for larger view.

WebInject is really an execution and reporting engine. Unlike the other tools, it has no IDE-style user interface, so tests must be written in an editor outside of the WebInject UI. This gives WebInject a less professional feel, but doesn't hamper the tool. I envision users of WebInject having directories filled with text files of various test “templates.” To add a new test case, the user just pops open his or her favorite editor, does some cutting, some pasting, and a bit of tweaking to alter the template to fit the specific circumstance, and ba-ding!, you've got a new test case.

When you launch WebInject, it reads an XML file containing a description of the test cases that the engine is to perform. Each test case is described by a set of attributes within an XML <case ... /> element. So, a simple test case that verifies that a specific Web method returns a list of book titles that includes My Antonia would look like this:

 <case

   id=”5”

   description1 = “Verify My Antonia in list”

   method=”post”

   url=”Http://localhost:8080/axis/bkService.jsw”

   postbody=”file=>soapListTest.xml”

   posttype=”text/xml”

   addheader=”SOAPaction: urn:getBookList”

   verifypositive=”My Antonia”

 />

The “id” attribute not only provides a unique name for the test case, it also identifies the execution order of test cases. The rest of the attributes are reasonably straightforward (once you've perused the documentation, at least). The value passed to the “postbody” attribute tells WebInject to go grab an XML file named “soapListTest.xml” in the current directory and use that to craft the SOAP content for the request.

Click for larger view.

If the result includes the string “My Antonia,” this test will succeed. WebInject provides three additional “verifypositive” attributes, and the value of each is treated as a regular expression. This means you can create quite complex verification specifications -- specifically, you can construct a test step that passes only after it has made it through the filters of four regular expressions, one for each “verifypositive” attribute. A test case element could also include four “verifynegative” attributes that work just the opposite of “verifypositive”: The testcase fails if any of the regular expressions match.

In essence, a WebInject “project” is nothing more than an XML file filled with a set of <case ... /> elements strung one after the other. WebInject's simple structure lets you build tests with amazing rapidity. You must, however, have a moderately good understanding of the mechanics of SOAP protocols as well as a tool that lets you generate and capture HTTP/SOAP requests and responses. You'll need the requests to build the POST body and the responses so that you can create proper “verifypositive” and “verifynegative” regular expressions to check for success or failure. I used the Web Service Toolkit add-on for Eclipse to grab requests and responses for WebInject; once I had gotten the hang of it, I fell easily into the groove of building test cases.