apetest
module
Smarter-than-monkey testing for web apps.
You can read about APE and how to use it on its home page. What follows here is a quick tour of the code.
Overview
APE consists of a core that crawls the web app/site under test to find pages to check. This core already does some checks, for example it reports HTTP errors, checks for inconsistencies in text encoding declarations and reports XML documents that are not well-formed.
When a document has been loaded, the core will offer it to all active
plugins to check. For example the HTML checker, even though it is core
functionality, is implemented as a plugin: apetest.plugin.checkhtml
.
Entry Point
main()
parses command line arguments and then calls
run()
to start a test run.
A test run starts by creating a Spider
to crawl the web
app/site under test, a Scribe
to collect the reporting
and a PageChecker
to load and check the pages.
After all pages have been checked, the core writes the test report. Finally, plugins are given a chance to create their final output as well and clean up after themselves.
Key Concepts
Since APE has no specific knowledge about the app it is testing other than
its URL, it cannot test state changes. Therefore it will not attempt
to change any server-side state, by making only HTTP GET
requests,
which should be idempotent.
The exact resource being requested is determined by the page URL and
an optional query; this is modeled by the Request
class.
A request is discovered by crawling other pages. Something that can
generate requests is called a referrer and is modeled by the
Referrer
class. Some referrers, like an HTTP redirect,
generate one exact request, while other referrers, like an HTML form,
can generate many different requests depending on the values of
the form's controls.
A request is considered speculative if an actual user accessing the web app/site through a web browser would not normally generate it. The server should be robust against such requests, but if it rejects them with an HTTP "client error" (400) status, APE will not report that as an error.
Source code
"""Smarter-than-monkey testing for web apps.
You can read about APE and how to use it on its
[home page](https://boxingbeetle.com/tools/ape/).
What follows here is a quick tour of the code.
Overview
========
APE consists of a core that crawls the web app/site under test to
find pages to check. This core already does some checks, for example
it reports HTTP errors, checks for inconsistencies in text encoding
declarations and reports XML documents that are not well-formed.
When a document has been loaded, the core will offer it to all active
plugins to check. For example the HTML checker, even though it is core
functionality, is implemented as a plugin: `apetest.plugin.checkhtml`.
Entry Point
===========
`apetest.cmdline.main` parses command line arguments and then calls
`apetest.cmdline.run` to start a test run.
A test run starts by creating a `apetest.spider.Spider` to crawl the web
app/site under test, a `apetest.report.Scribe` to collect the reporting
and a `apetest.checker.PageChecker` to load and check the pages.
After all pages have been checked, the core writes the test report.
Finally, plugins are given a chance to create their final output
as well and clean up after themselves.
Key Concepts
============
Since APE has no specific knowledge about the app it is testing other than
its URL, it cannot test state changes. Therefore it will not attempt
to change any server-side state, by making only HTTP `GET` requests,
which should be idempotent.
The exact resource being requested is determined by the page URL and
an optional query; this is modeled by the `apetest.request.Request` class.
A request is discovered by crawling other pages. Something that can
generate requests is called a *referrer* and is modeled by the
`apetest.referrer.Referrer` class. Some referrers, like an HTTP redirect,
generate one exact request, while other referrers, like an HTML form,
can generate many different requests depending on the values of
the form's controls.
A request is considered *speculative* if an actual user accessing the web
app/site through a web browser would not normally generate it. The server
should be robust against such requests, but if it rejects them with
an HTTP "client error" (400) status, APE will not report that as an error.
"""}
Sub-modules
apetest.checker
-
Checks a document for problems and finds links to other documents …
apetest.cmdline
-
Command line interface.
apetest.control
-
Models form controls …
apetest.fetch
-
Load documents via HTTP …
apetest.plugin
-
APE's plugin infrastructure …
apetest.referrer
-
Models links between documents …
apetest.report
-
Gathers and presents checker results in a report …
apetest.request
-
Home of the
Request
class. apetest.robots
-
Functions for handling robot exclusion files ("robots.txt") …
apetest.spider
-
Keeps track of links between pages …
apetest.version
-
Package version info.
apetest.vnuclient
-
Client for using the web service of the Nu Html Checker (v.Nu) …
apetest.xmlgen
-
A friendly syntax to create XML in Python …