Release: FitLibraryWeb - a new download

View: New views
1 Messages — Rating Filter:   Alert me  

Release: FitLibraryWeb - a new download

by Rick Mugridge :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

A new set of fixtures are now available as a separate download from the
FitLibrary in Java site.

Cheers, Rick

/FitLibraryWeb/ extends /FitLibrary/ with a set of fixtures for testing
web applications, web services, XML, email, PDFs, as well as recording
and mocking web services. It is provided as a separate download because
of size. This is due to the large number of JARs that it depends on and
that are included in the download.

/FitLibraryWeb/ was kindly donated by /Air New Zealand/ in October 2009.
It was developed by Rick Mugridge and Darren Rowley while Rick was on
contract at /Air New Zealand/ from May 2008 - October 2009.

For downloading /FitLibraryWeb/, go
to http://sourceforge.net/projects/fitlibrary/. This depends on the
latest version of /FitLibrary/.

The download contains documentation and comprehensive specifications
for /FitLibraryWeb/ itself.


    SpiderFixture

/SpiderFixture/ supports the specification and testing of web systems
based on HTML and ajax. It can be run through a variety of browsers.

/SpiderFixture/ is based on [/WebDriver/
<http://code.google.com/p/webdriver/>, which has pluggable
implementations for browsers (FireFox, IE, Google Chrome) as well as for
"head-less" testing with /HtmlUnit/. It has coming support for iPhone
and general Selenium.

/SpiderFixture/ has a comprehensive set of actions for emulating a use
on a web browser. It can check and manipulate forms, tables, inputs,
selects, frames/iframes, windows (including popups). It can also execute
JavaScript on the browser, and include screendumps in the report (when
supported by the underlying browser).

It has built-in support for ajax (ie, JavaScript acting on the browser).
It automatically polls for an element to appear, before checking or
acting on it. This has a timeout period that can be set at any point in
the storytest. This mechanism avoids the need for including sleeps in a
storytest. The test delays only as long as necessary, so it does not do
unnecessary waiting. Using /DoFixture'/s *becomes* action (and
variants), a test can also automatically poll for the value of the text
or attribute of an element to becomes what's expected.

It's possible to run more than one copy of /SpiderFixture/ at once, such
as to emulate two users of a chat system. This is supported
through/FitLibrary'/s /SelectFixture/.


    XML

/XmlDoFixture/ is a thin layer on top of [/xmlUnit/
<http://xmlunit.sourceforge.net/>]. It has actions for:

    * Comparing two XML documents (diff)

    * Transforming with xslt

    * Checking for xpath values


    Web Services

/WebServicesClientFixture/ permits SOAP and other web services to be
specified and testing.

This is based on the apache open-source system [/HttpClient/
<http://hc.apache.org/httpclient-3.x/>].


    Recording Web Services

The Recorder will pass through and record web service calls on multiple
ports. For each port, for each web service call:

    * The call is passed on to the real web service
    * The result from that call to the real web service is returned
    * The request and response are saved to files

These recordings can then be altered (such as through the use of
templates) to support mocking of web services.


    Mocking Web Services

Why mock?

Consider a system ("our" system), which is being tested. It makes web
service calls to other systems, to gather data or have an impact on
those other systems.

It can be difficult to test our system when we don't have complete
control of those other systems, or when those other systems are yet to
be updated to handle our changes. Even if we can set up those other
systems to respond appropriately, it can be a pain to coordinate. So
often we're forced to test in the context of those other systems, making
use of their current data. That brings its own problems.

It may be difficult to force those other systems to respond in odd ways
(eg, with obscure errors), so it makes it very difficult to test our
error-handling. For example, does our system react correctly, such as
informing the user, if another system is unavailable for a few seconds.

There may also be problems with calling a web service that has serious
impacts, such as carrying out a credit card payment.

A reasonable approach to these problems is to mock the web service to
each of those other systems. This means that the test defines how
another system should respond. Because the test is written to test
certain behaviour, it's often OK to work out what specific ways the
other systems should respond. There are techniques that help in defining
the mock behaviour, as we discuss in the documentation.

/MockWebServicesFixture/ allows for one or more web services to be
mocked, on one or more ports. It has a way of defining complex options,
sequences and repeats of service calls. A particular web service call
from the system and test can be matched in various ways to determine the
response.


    Shell Fixture

/ShellFixture/ allows a "shell" command to be executed, such as to ftp a
file, and to monitor the responses. This can be useful when a storytest
has to interact with the file system or some other application at some
point in a larger test.

/ShellFixture/ is a variant of a fixture available with /!-FitNesse-!/,
but which integrates well with /FitLibrary/.
As /!-FitLibrary's-!/ /SelectFixture/ allows for multiple fixtures to be
running at once, this fixture provides a single shell command.


    Create Dates

Including actual dates in storytests can be a pain, as they need to be
changed to make sense.

The /CreateDate/ fixture creates dates/times in the past and future, for
different time zones. It takes a date format to specify the detailed
form of the date/time required.

It is based on [/Joda Time/ <http://joda-time.sourcefoge.net/>].

It is a good example of a "micro-DSL".


    Databases

/MySQL/ and /Oracle/ are two simple fixtures that wrap fixtures
from /DbFit/, so that they can be used as part of a larger storytest,
with/SelectFixture/ in /FitLibrary/.

The underlying fixtures are in [/DbFit/
<http://gojko.net/fitnesse/dbfit>], written by Gojko Adzic.


    Electronic Mail

The /ElectronicMail/ fixture allow for testing that email has been sent.
It has actions to:

    * Connect to a email server

    * Open a Folder

    * Select a message that matches some criteria

    * Check the message body for string matches

    * Check that it has an attachment, and to download it

    * Delete a message

This we created by Darren Rowley. It makes use of the [/javamail/
<http://java.sun.com/products/javamail/>] system.


    PDFs

The /PDFDocument/ fixture allows for the text within a PDF file to be
checked.

It has commands to:

    * Open a PDF file:

    * Check a string appears somewhere in the text in the whole document:

    * Confirm the number of pages:

    * Select a specific page:

    * Select the text below a given heading and up to the next heading
      (can also use *contains* and *matches*:

    * Check that a string appears somewhere in the text of the current page

    * Dump an image of the PDF and include it in the storytest report:

This we created by Darren Rowley. It makes use of the apache open-source
[/pdfbox/ <http://incubator.apache.org/pdfbox/>] system.