Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This Test Suite has been designed primarily to help implementers evaluate conformance to the XHTML-Print W3C Candidate Recommendation 20 January 2004. It is based upon the W3C HTML4.1 Test Suite.
The XHTML-Print Test Suite is based on the XHTML-Print Candidate Recommendation 20 January 2004. This test suite is applicable to user agents such as printers. Other means should be used to validate an XHTML-Print document or client conformance. The test suite consists of the following:
This document explains how to use and access the tests of the XHTML-Print Test Suite. The XHTML-Print Test Suite is not in the TNG format used by the HTML Test Suite, since only support for JPEG images in the object element is required of a conforming XHTML-Print User Agent.
The cover page of the test suite contains a table of contents, structured parallel to the XHTML-Print specification. The test suite contains a Prologue which documents among other things requirements or recommendations for a specific system configuration, or suggestions for setting your system preferences in such a way as to minimize their interference with the tests themselves. The cover page references test lists that reference individual tests.
Get started with running the tests in a test suite by downloading one or more tests and sending them to the printer one after the other.
The test content is self-describing - that is, the test content contains a textual description of what the page should look like according to the test, e.g. 1. This first item of an ordered list should be numbered
XHTML-Print User Agents must accept XHTML-Print documents both as document and a multiplexed document. The app_multiplexed utility creates a multiplexed document from the an XHTML-Print document.
Several tests in this test suite have to do with facets of processing the multiplexed document format and the multiplexed document version of the XHTML-Print document should be tested rather than the XHTML-Print file. These tests can be created from their XHTML-Print document using the app_multiplexed utility provided with this test suite in conjunction with the Makefile placed with the tests.
The test suite core is the test pages that exercise the features of XHTML-Print. Each test page is referenced by a test list page. Also, the test suite starts with a cover page, which links directly to each of the test list pages. Here is a visualization of the relatively flat conceptual hierarchical structure of the test suite:
The individual types of pages in the test suite format are described from the inside out.
The XHTML-Print test pages typically contain the test purpose and assertions tested stated in a <div class="TestPurpose"> and <div class="AssertionsTested"> block, e.g.
Verify that ordered and unordered lists are rendered. Tests for assertions 10.2-8, 10.2-9
Followed by a series of tests, each of which tests one item clearly. There may also be compound tests that follow the atomic tests.
Each test contains prose which describes the correct behavior.
The test pages use valid XHTML-Print.
Finally, the test is named by the section.subsection number of the section being tested (with periods replace by underscores e.g. 1_1), a hyphen, a test type, a hyphen, a two digit number. E.g. 1_1-BF-01. This follows the HTML4.01 test file naming conventions. The underscore in the section name allows better tracking to the relevant section of the specification. The test type gives an indication of the type of test. Test types include:
The two digit number allows otherwise identical names to be used.
Test file names should be the same as the test title with the proper suffix (almost always .html) appended. E.g. 1_1-BF-01.html Supporting files for the test should be named with an alphabet character after the test name and before the .html suffix. E.g. 1_1-BF-01a.html. Generic supporting files such as image files may be named differently.
The test suite's cover page begins with the W3C logo and a heading stating the
name of the test suite which is also used for the page
<title>, e.g.,
XHTML-Print Test Suite
A short paragraph of text introduces the test suite, and documents its purpose, usage, and any caveats. Another paragraph minimally explains the structure of the test suite itself. Any additional test suite specific documentation is in the Prologue. A subheading labels the Table of Contents which immediately follows the introductory text.
The table of contents is a simple list of numbered hyperlinks ( e.g.: 10 Lists ) to the section pages. Following the numbered section pages for the tests, there may be one or more lettered pages for test suite appendices, such as A. Acknowledgments, B. Test Suite Errata, and C. Related Resources.
A horizontal rule separates the Table of Contents from the cover page footer. The footer contains a mailto hyperlink for test suite feedback, and recognition of the organizations responsible for the production of the test suite, along with their respective logos.
The authoring of a test suite for a particular specification begins with the identification of testable assertions in the specification grouped by section and subsection of the specification.
Try to make use of existing test pages, by reference if possible rather than duplicating. Some specifications, such as profiles, do not contain new features of their own. New versions of specifications often build upon features of older specifications. In both cases, it should be possible, and it is desirable, to reuse existing test cases.
Start by creating a new directory for your test suite, and copying the necessary support files (listed below). All test suite files for your test suite will go into this one directory.
This template is derived from the CSS1 Test Suite. Test authors MUST use this template to write new tests.
The template for a test page is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML-Print 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-print10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>test name e.g. 10_2-BF-01</title>
</head>
<body>
<div class="TestPurpose">Verify some test purpose</div>
<div class="AssertionsTested">Tests for assertions assertion_number</div>
/* enter self-documenting test here */
</body>
</html>
Tests come in two formats:
The test suite, therefore, contains test pages in both formats.
A multiplexed document is created using the app_multiplexed utility. Multiplexed document tests have a file suffix ".mx".
Some basic principles have been learned during the construction of previous test suites, applicable to both graphics suites and others:
All tests must test what they purport to test and all files in the test suite, whether harness or tests themselves must at a minimum be conforming XHTML-Print documents.
The tests should be self-documenting. Test cases should describe in prose, in the test cases themselves, what is expected. Each test case should at a minimum describe correct behavior. Error handling tests should at a minimum describe incorrect, or possibly unexpected behavior.
Simplicity is always a good design principle. Failure of a test should be caused by the assertion being tested and not because of numerous variables introduced by a complex test. A simple format also makes it easier to author and test executer to analyze the test.
A test suite should contain atomic (meaning, testing a single feature at a time) tests. Some features have little or no effect by themselves, and therefore may require simple compound tests at a minimum.
Tests must be based upon, and traceable to, testable statements in the specification being tested. The XHTML-Print test suite will be based on the testable assertions document.
Without sacrificing the principle of atomic testing, the number of test instances (files) can be reduced by having a single instance combine multiple related test purposes.
Ease of authoring to implies that the test suite format must be easily hand written, that is, easily written with only the use of a simple text editor without a dependency upon any particular tools or any particular platform or device.
Test suites should begin with simpler, easier test cases, and proceed to more complex, more challenging tests. This makes sense both from a test case authoring perspective, since simpler cases are easier to author, and from a technology implementer's perspective, since simpler cases are easier to implement.
The detailed tests should try to methodically vary and test all values, plus boundary conditions and extreme conditions, of each parameter, attribute, or property.
When writing a test suite for a particular technology (e.g. XHTML-Print), it is may be necessary to utilize other technologies such as CSS in the construction of that test suite. Test suite authors must be careful while testing one technology, to avoid testing other technologies. Those other technologies should be used in such as way as to be maximally compatible, in a way that is most forgiving to the various user agents which will be using the test suite. Consequently, HTML test suite files should:
Test suites should attempt to reuse test cases from previous test suites.
Finally, as with any set of principles and requirements, there are some non-requirements. These non-requirements are exactly that - they are features not required of a test suite. They may be desirable, or even included - yet they are not necessary to produce a test suite.
This XHTML-Print Test Suite Documentation is mostly an edited version of the HTML Test Suite Documentation and this document would have been very difficult to create without it. The XHTML-Print Test Suite is derived from the work of many people at the W3C and other organizations and companies.
Feedback regarding the XHTML-Print Test Suite should be sent to www-html-testsuite@w3.org.