Copy as Markdown
Annotation-Protocol: Tests for the Web Annotation Protocol
The [Web Annotation Protocol](https://www.w3.org/TR/annotation-protocol)
specification presents set of messages to allow Annotation clients and servers
to interact seamlessly.
The purpose of these tests is to help validate that clients send and are
capable of receiving correctly formatted messages, and that servers are
able to receive and respond to correctly structured requests.
The general approach for this testing is to enable both manual and
automated testing. However, since the specification has no actual user
interface requirements, there is no general automation mechanism that
can be presented for testing clients. Also the server tests need to be
pointed at a server implementation to exercise. However, once provided
the basic information, testing is automated.
Implementors could take advantage of the plumbing we provide here to
help their implementations talk to the endpoint we provide or exercise
their endpoint with the provided server tests. This assumes knowledge
of the requirements of each test / collection of tests so that the input
data is relevant. Each test or test collection contains information
sufficient for the task.
With regard to server tests, the browser tests we provide can be
pointed at an endpoint and will exercise that endpoint using well
defined messages. This is done semi-automatically, although some set-up
In the case of this test collection, we will be initially creating manual
tests. These will automatically determine pass or fail and generate output for
the main WPT window. The plan is to minimize the number of such tests to
ease the burden on the testers while still exercising all the features.
The workflow for running these tests is something like:
1. Start up the test driver window and select the annotation-protocol tests -
either client or server - then click "Start".
2. A window pops up that shows a test - the description of which tells the
tester what is required. The window will contain fields into which some
information is provided.
3. In the case of client testing the tester (presumably in another window) brings up their
annotation client and points it at the supplied endpoint. They they perform the
action specified (annotating content in the test window, requesting an annotation from the server, etc.).
4. The server receives the information from the client, evaluates it, and reports the result of testing.
In the event of multi-step messages, the cycle repeats until complete.
5. Repeat steps 2-4 until done.
6. Download the JSON format report of test results, which can then be visually
inspected, reported on using various tools, or passed on to W3C for
evaluation and collection in the Implementation Report via github.
**Remember that while these tests are written to help exercise implementations,
their other (important) purpose is to increase confidence that there are
interoperable implementations.** So, implementers are our audience, but these
tests are not meant to be a comprehensive collection of tests for an implementor.
The bulk of the tests are manual because there are no UI requirements in the
Recommendation that would make it possible to effectively stimulate every client portably.
Having said that, because the structure of these "manual" tests is very rigid,
it is possible for an implementer who understands test automation to use an
open source tool such as [Selenium](http://www.seleniumhq.org/) to run these
"manual" tests against their implementation - exercising their implementation
against content they provide to create annotations and feed the data into our
test input field and run the test.
Capturing and Reporting Results
As tests are run against implementations, if the results of testing are
submitted to [test-results](https://github.com/w3c/test-results/) then they will
be automatically included in documents generated by
[wptreport](https://www.github.com/w3c/wptreport). The same tool can be used
locally to view reports about recorded results.
Automating Test Execution
If you are interested in writing tests for this environment, see the
associated [CONTRIBUTING](CONTRIBUTING.md) document.