test-sqrl

Always implement test coverage for major features or complex data transformations implemented in SQRL. Prefer table tests. Use API tests for complex interaction patterns (mutation followed by query/subscription) or authorization.

Writing Tests

Test Types

DataSQRL supports two snapshot test types (run via test command):

1. Table tests: SQRL tables annotated with /*+test */ hint
2. API tests: GraphQL operations (queries/mutations/subscriptions) in a configured test folder.

Table Tests

Add /*+ test */ hint to any table definition:

-- Tests that the query returns an identical snapshot of data
/*+ test */
CustomerRetrievalTest :=
SELECT customerid, name, email
  FROM Customer
  WHERE name = 'John' ORDER BY customerid;

-- Tests an invariant and returns failing records
/*+ test(no_rows) */
InvalidCustomersTest :=
SELECT * FROM Customer
  WHERE name = '' OR email IS NULL;

Requirements:

• Use /*+ test(no_rows) */ hint to test invariants
• Snapshot results must have deterministic order (use ORDER BY)
• Only select predictable columns and exclude non-deterministic ones (e.g. columns computed via RAND() or NOW())
• Table tests do not include relationships
• Every column in ORDER BY must also appear in SELECT. To sort by a column without including it in snapshot output, alias it with a _ prefix: event_time AS _event_time. Omitting an ORDER BY column from SELECT causes: All sort columns must be part of the SELECT clause for table definitions, missing: [col].

API Tests

Place .graphql files in the configured test folder, one operation definition per file. The file name (without extension) is the test name and the snapshot name: every query/mutation/subscription block in a file is registered under that name, so a second block in the same file is compared against the first one's snapshot and fails on every run. One block may still query several root fields at once (use aliases: byOrg: alerts(...) {...} byDeployment: alerts(...) {...}); that is a single operation and a single snapshot.