Package uk.ac.sheffield.vtts.gui

This package contains a simple Java Swing graphical user interface that allows you to run the Broker@Cloud Verification and Testing Tool Suite as a stand-alone Java application.

See: Description

Class Summary

Class	Description
BrokerAtCloudVTTS	BrokerAtCloudVTTS is a Java Swing GUI that demonstrates the verification and testing tools.

Package uk.ac.sheffield.vtts.gui Description

This package contains a simple Java Swing graphical user interface that allows you to run the Broker@Cloud Verification and Testing Tool Suite as a stand-alone Java application. It is part of the Broker@Cloud Verification and Testing Tool Suite, v1.0, © Anthony J H Simons and Raluca Lefticaru, 2015. Main web site: http://staffwww.dcs.shef.ac.uk/people/A.Simons/broker/.

Package uk.ac.sheffield.vtts.gui

This package contains a simple Java Swing graphical user interface that allows you to run the Broker@Cloud Verification and Testing Tool Suite as a stand-alone Java application. This application allows you to:

• validate an XML service specification, to check whether the state transition diagram is sensible and appropriate;
• verify an XML service specification, to check whether the operation specifications are consistent and complete;
• generate a technology-neutral XML test suite from an XML service specification, to cover all the states and transitions of the specification;
• translate a technology-neutral XML test suite into one of three different JUnit formats, expected by platform-specific Java service clients.

Dependencies

These tools depend directly on two libraries; but any test code you later generate will depend on different libraries, depending on the kind of technology you use for your cloud software services. For convenience, we have bundled the essential library files to accompany this distribution:

• jast-1.1.jar - XML marshalling and unmarshalling software
• jsyntaxpane-1.0.0.jar - XML and Java syntax pretty-printer

All tools use the Java Abstract Syntax Trees (JAST) package for marshalling and unmarshalling, © Anthony J H Simons, University of Sheffield, available from: http://staffwww.dcs.shef.ac.uk/people/A.Simons/jast/. If working with JDK, you should install JAST 1.1 (or any later version) in the same place that you unpack this software. If working in an IDE (such as Eclipse, NetBeans, etc.) you should configure your build path to include jast-1.1.jar.

The GUI front-end also uses the JSyntaxPane package for pretty-printing XML and Java syntax, © Ayman Al-Sairafi, ACI Worldwide, Bahrain (hosted at Google Code), and extended by Hanns Holger Rutz, SCISS, Germany (hosted at GitHub). If working with JDK, you should install JSyntaxPane 1.0.0 (or any later version) in the same place that you unpack this software. If working in an IDE (such as Eclipse, NetBeans, etc.) you should configure your build path to include jsyntaxpane-1.0.0.jar.

While these are the only dependencies required by the verification and testing tool suite, you will generate Java code designed for JUnit 4. We recommend that you install the JUnit 4 library available with your Java IDE. If you generate code just for testing "plain old Java objects" (POJOs), then this is all you will need to execute the generated tests. If you generate code for JAX-WS SOAP web services, then this will depend on whatever Java service client classes that you generate from the service's WSDL, using the JAX-WS tools. If you generate code for JAX-RS REST web services, then this code will depend on the Apache Jersey 1.19 reference implementation of a REST web-server, and also use Google Gson 2.3.1 to unmarshal JSON data. All these packages are widely available at no cost.

Usage

A service specification is developed in stages. First the designer should validate the specification, to be sure that they have chosen the intended states and transitions for the service, Later, they should verify that the logical conditions specified for each operation are consistent and complete. When the specification is known to be correct, and has passed the validation and verification stages, the designer may generate high-level abstract tests from the specification, in a technology-neutral format, ensuring that all the states and transitions of the specification are covered. Finally, the designer may generate concrete JUnit test-driver code from the high-level specification, in one of several formats that assume testing either a SOAP or REST web-service, or even a plain old Java object.

A service specification is developed in the XML service specification language developed for Broker@Cloud, for which the XML schema (XSD) can be found here: http://staffwww.dcs.shef.ac.uk/people/A.Simons/broker/ServiceSchema.xsd. The website above also contains examples of specifications conforming to this schema, as illustrations. The four tools are intended to help the designer develop a relevant and correct specification, and should be applied in the given order: validation, verification, test generation, test grounding. Each subsequent tool assumes that the specification has been passed by the previous tools. If not, then arbitrary results may ensue.

To launch the stand-alone Java Swing application, either double-click on the icon for the tool on your desktop; or load the class BrokerAtCloudVTTS in your Eclipse IDE and select Run from the Eclipse main menu. Each of the functionalities is supplied under a different tabbed pane.

• Validation: validates a specification looking for missing transitions in the state machine. Checks all handled and ignored events, so that the designer may be confident of handling the desired events in each state.
• Verification: verifies a specification for logical consistency and completeness. Checks that all the guarded paths through each operation are mutually exclusive and exhaustive, such that there is no blocking or nondeterminism.
• Test Generation: generates a high-level test suite from a specification. Simulates the whole specification model (machine and protocol), generating test sequences up to a given maximum length, and optionally compressing the results.
• Test Grounding: generates a concrete JUnit test driver, based on the assumption that the service-under-test is either: a plain old Java object; a JAX-WS SOAP web service; or a JAX-RS REST web service. These are examples on which to base your own grounding.