Add a =test block to the specification. A worked example then carries the shape it should parse into, next to the example itself.
Assertions use Podlite's own selector syntax. They check the parsed structure, not rendered output, so any conformant parser can run the same tests.
Example
=begin test :id<heading-carries-its-level>
=begin fixture
=head2 Overview
=end fixture
=for assert :caption('a second-level heading is recognised as such')
head2[ ]
=end testA runner takes each =test block, parses the =fixture body, checks each =assert selector against the result, and reports pass or fail.
Scope
=test container, named by :id=fixture child: a verbatim body. Each one is a document of its own=assert child: one selector expression. :absent inverts it=resource child: content reachable by a path while the test runs- what a result must tell apart, with no format fixed
Why
Four regressions in v0.8.x of the desktop editor came from worked examples of this specification: podlite/podlite-desktop#70, podlite/podlite-desktop#61, podlite/podlite-desktop#58, podlite/podlite-desktop#62.
One of them was a crash. The other three gave a valid result with the wrong meaning, which a smoke gate cannot see.
podlite/podlite#13 describes a pre-release gate in two phases. Of the second it says: depends on a separate spec proposal (the =Test block shape), in preparation. This issue is that proposal.
podlite/podlite-desktop#53 asked whether an overview of specification-versus-implementation differences exists. There was none.
Status
Integration comes in two parts. Everything but the section on linking a vocabulary of values to a check depends on nothing outside the norm. That section depends on additions belonging to #39 and #38
Add a
=testblock to the specification. A worked example then carries the shape it should parse into, next to the example itself.Assertions use Podlite's own selector syntax. They check the parsed structure, not rendered output, so any conformant parser can run the same tests.
Example
A runner takes each
=testblock, parses the=fixturebody, checks each=assertselector against the result, and reports pass or fail.Scope
=testcontainer, named by:id=fixturechild: a verbatim body. Each one is a document of its own=assertchild: one selector expression.:absentinverts it=resourcechild: content reachable by a path while the test runsWhy
Four regressions in v0.8.x of the desktop editor came from worked examples of this specification: podlite/podlite-desktop#70, podlite/podlite-desktop#61, podlite/podlite-desktop#58, podlite/podlite-desktop#62.
One of them was a crash. The other three gave a valid result with the wrong meaning, which a smoke gate cannot see.
podlite/podlite#13 describes a pre-release gate in two phases. Of the second it says: depends on a separate spec proposal (the
=Testblock shape), in preparation. This issue is that proposal.podlite/podlite-desktop#53 asked whether an overview of specification-versus-implementation differences exists. There was none.
Status
Integration comes in two parts. Everything but the section on linking a vocabulary of values to a check depends on nothing outside the norm. That section depends on additions belonging to #39 and #38