Specifications

Every rule below is a test. These pages are generated from the test suites of the four TableTest products, so each rule you read is executable, each scenario is one row of a table that runs in CI, and a rule can only be published if it passes.

That is the point of the format: a specification written as examples cannot quietly drift from the code it describes. When behaviour changes, the table that documents it fails.

The four specifications

• TableTest JUnit — how a table becomes test scenarios: what each cell value converts to, what the table syntax means to the test runner, and worked examples
• TableTest Parser — the grammar of the table format itself: how text divides into rows, rows into cells, and a cell into a value
• TableTest Formatter — how a table is laid out, ordered as the formatter works: finding the tables, measuring the cells, sizing the columns, indenting the result
• TableTest Reporter — how results become published pages. Generated by the tool it documents

How to read them

Each specification is a tree of features, and each feature holds rules. A rule is one statement about behaviour, followed by the table of scenarios that establishes it — one row per case, with the inputs on the left and the expected results on the right, marked ?.

Pass and fail counts are rolled up per page, so a feature index shows at a glance how much of it is covered and whether all of it currently holds.

What they are not

These are curated specifications, not user guides. They document the rules each product follows, in depth, but they do not walk you through getting started or explain when to reach for a feature. For that, read Learn and Reference.

Some behaviour is also deliberately absent: a rule that can only be stated beside code the report cannot show — a custom converter’s body, an internal mechanism — stays as an ordinary test rather than being published here.