Features and tests

A feature is something your app does, named the way your ticket names it, such as Users, invitations and permissions. Tada checks a feature end to end, and a feature is Passing or Failing.

A feature’s proof is made of tests. A test is one part of that proof, such as As a viewer, Finance stays closed. It is a few plain steps, and the words that should be on screen when it works.

Overview

Word	What it means
Feature	Something your app does, named as the ticket. Passing or Failing.
Test	One part of a feature’s proof, such as what one person can and cannot do.
Check	One go at one feature. It walks the feature’s tests and ends Passed or Failed. See Checks and reports.
Result	One test’s outcome inside one check: Passed, Failed or Not reached.

A test’s steps look like this:

- goto /cart
  expect: 1 item in your cart
- fill Promo code with SPRING
- click Pay now
  expect: Order confirmed

A step is an action, such as click Pay now. An expect: under a step names words that must be on screen after it. There are no selectors to maintain and no framework to learn.

Where features come from

You and your team make the features in your list.

How	What happens
Your coding agent, from a ticket	The agent sends the ticket, and Tada answers with the tests that would prove it. You confirm them. The agent writes the steps, and Tada walks every test and saves the feature under the ticket’s name. See Check what your coding agent builds.
Rivet	Ask her to prove something works, and she writes the tests from your screens. See Rivet.
A file your team commits	A test file names its feature on its feature: line. See Tests kept in your repository.

Tada also learns your app by itself. What it learns helps it plan a proof, and stays out of your list. The one exception is the feature Tada checks to show you, after you connect GitHub. See Add an app.

See a feature

1. Open Features. Each row is a feature, with its app, its tests and its state: Passing, Failing, Flaky or Not checked yet.
2. Open a feature. The line under its name says where it stands, and an open issue sits beside it when it is Failing.
3. Demo plays the film of its newest passing check. Checks lists every check, newest first, and each opens its report. Tests lists what a check proves, each with its latest result.
4. Press Check now to check it again, or Ask Rivet to change how it is tested.

A test that is switched off is left out of every check until it is switched on.

Tests kept in your repository

Tada keeps every feature and test itself, and never writes into your repository. If your team wants a test reviewed in the same diff as the code, you can commit it as a file under .tada/flows/. This is optional. The folder keeps its older name so files already committed keep working.

Tada reads those files at the commit that deployed. Change a feature and its file in the same commit, and the check on that commit uses the new version. If a file and Tada disagree, the file wins on the next deploy. See Test file syntax.

Write a good test

• Expect words a person can read on the page. expect: Order confirmed passes when those words appear. expect: the order went through never passes, because no page says that.
• Expect the payoff. A test that ends on a click proves the click happened, not that it worked. Every test needs at least one expect:, and only camera steps such as caption or wait may follow the last one.
• Pick words that appear only after the step worked. Words already on the page, like a menu label, pass whatever happened.
• Mind the data. Each environment has its own database. A test that opens an invoice seeded only on staging will be Failed on production.

Next

• Checks and reports: what starts a check, what it costs, and how to read its report.
• Test file syntax: every step, with an example.