An application keeps its own tests in _tests/. A test is a page there - cart.pad, with cart.php when it needs data - next to its answer, cart.txt. pad test shop renders every test page and compares:

$ pad test shop
shop
  ok    cart
  FAIL  checkout
        want: <p>Total 42</p>
        got:  HTTP 500 - assert failed: $total eq 42
              apps/shop/_tests/checkout.pad:1:1  {assert $total eq 42}
  2 tests, 1 failed

The answer

• the exact output of the page, trimmed;
• /a pattern/ matched over it - for output that changes, a date or a count;
• HTTP 500, with an optional /pattern/ on the next line, for a test that is meant to fail.

A test without an answer counts against the run; pad test shop --record writes the missing answers from what the pages render now, and never overwrites one. pad test --all runs every application that has tests, and ./ci.sh does that as its apptests line.

Asserts

{assert} holds a page to a condition during a test run: false, and the test fails with the condition and the message as its report. Anywhere else it is silent - the condition is not even evaluated - so it can stay in the application's own pages. The switch is $padAssert, which pad test turns on; this example turns it on in its PHP:

<?php

  $padAssert = TRUE;

  $total = 42;

?>

{assert $total eq 42, 'the cart total'}
<p>Total {$total}</p>

A test page

It is a page like any other, rendered bare - without the application's wrappers - and no URL reaches it. It can bring in a real page with {page 'cart'}, or include the page's own PHP and check the data it sets:

_tests/cart.php    <?php include APP . 'cart.php'; ?>
_tests/cart.pad    {assert $total eq 42, 'the cart total'}
                   <p>Total {$total}</p>
_tests/cart.txt    <p>Total 42</p>