Skip to main content
Your app comes with its own test suite. The builder writes the tests while it writes the code, and each test names the rule it proves. Creator runs the suite every time a story is verified, and shows you what it said. The suite is part of your app. It is in your code, it goes with the code when you export it, and your own developers can run it.

​
What a test proves

Every story has rules: what the app must refuse, what it must limit, who may do what, what happens to a record after an action. Each rule has a short id. A test carries the id of its rule in its name:
That is how Creator knows which rule a test is about. A test with no id still runs and is counted. It proves no rule.

​
The four states of a rule

When the builder cannot test a rule, it says so in the suite, with the reason. You see the reason beside the rule.

​
Test strength

A test that can never fail proves nothing. To find those, Creator makes small deliberate changes to the code a story wrote, one at a time, and runs the story’s tests again. It reverses a comparison, moves a limit, swaps an “and” for an “or”. The changes are made in a copy; your app and your preview are never touched. Test strength is measured a few minutes after a story is verified, so it appears a little later than the counts. It never changes whether a story is verified or built.

​
Where you see it

The line on the publish screen is information. It does not decide whether you can publish.

​
Tests that read or write data

Some tests need a database. They get one of their own, emptied before every run and filled with the app’s own starting records. Your app’s data is never used by a test. If that database cannot be made ready, the tests that need it read “could not run”, and Creator says why.

​
Running the tests yourself

The Tests tab shows the command. For most apps it is:

​
Quick builds

A Quick build is not asked to write tests. If it has tests anyway, Creator runs and counts them.