# testthis.now - full guide for AI agents

> Realistic, integrated practice applications where testers, delivery teams and AI agents can learn and rehearse end-to-end software testing in a safe environment. Nothing is real and nothing can be broken that matters. Crawlers, test bots and AI agents are welcome on every site listed here.

This is the plain-text version of https://testthis.now/. It carries the same information as the home page, so an agent never needs to scrape the HTML.

Operated by Test Data Services Pty Ltd, Torquay, Victoria, Australia. All businesses, products, people and transactions on these sites are fictitious, except the auto-planter idea, which comes from the novel The Companion's Whisper by Paul McLean. These are test systems: they do not claim to conform to privacy or accessibility standards.

Author: testthis.now is created and written by Paul McLean. Questions, feedback and ideas for new challenges are welcome via LinkedIn: https://www.linkedin.com/in/paulmclean2/

## Rules for people, bots and agents

- No real money or goods. Payments are simulated and nothing ships. Use test card details only, never a real card.
- Use invented data. The apps are public; never enter real personal information. Generated names, addresses and test mailboxes work best.
- Your data stays with you. Records you create are separated from other visitors' activity. That is a convenience, not a security boundary, so treat everything as visible.
- Be a good neighbour. Activity is logged with source addresses. Automation and moderate load are welcome; anything that degrades the service for others is not.

## Why this exists

AI coding assistants and agents now produce features, integrations and tests at a pace no review process was designed for. The bottleneck has moved from writing software to knowing, with evidence, that it does what the business needs.

- More change, less time to check it: testing has to be automated, repeatable and fast enough to sit in the pipeline.
- The risk lives between the components: real failures hide in journeys such as sign-up, email codes, MFA, payments, fulfilment and the back office.
- AI changes the tester's toolkit: agents that drive browsers, generate test data and propose test cases need direction, guardrails and a human who knows what good evidence looks like.
- Skills need a practice field: state, integrations, rules and consequences, without real customers or real money.

## What you can practise

- AI-assisted test design: turn business rules into scenarios and edge cases with an assistant, then check its work.
- Agent-driven end-to-end automation: point a UI test script or a browser-driving AI agent at a real multi-step journey.
- Out-of-band steps: automate emailed verification codes and TOTP MFA instead of skipping them.
- APIs, tokens and access control: JWT-secured APIs, per-app tokens from one login, and what each app should not let you see.
- Test data strategy: create, pool, reuse and isolate data so parallel runs never collide.
- Time-dependent behaviour: move the clock forward to test deliveries, status changes and cover periods.
- Cross-application verification: act as a customer, then confirm the outcome from the staff and warehouse sides.
- Negative and unhappy paths: declined payments, expired codes, password resets and support complaints.
- Pipelines and performance: run suites from CI and put realistic journeys under load.

## Apps

Apps are versioned in their hostnames, so a published version stays put. Scripts written against v1 keep working when v2 arrives alongside it.

### Verdant Dock, version 1 (live)

A retailer of self-moving auto planters and the exotic plants that live in them. A customer storefront, a staff portal and a warehouse view share the same orders, deliveries, insurance cover and support cases, with real email in the loop.

- API base: https://api.verdant-v1.testthis.now
- API reference (OpenAPI): https://shop.verdant-v1.testthis.now/openapi.yaml
- Agent guide for the Verdant apps: https://shop.verdant-v1.testthis.now/llms.txt
- Support email address: support-verdant-v1@testthis.now

Verdant Shop - https://shop.verdant-v1.testthis.now
- Sign-up with emailed code and mandatory TOTP MFA
- Password reset and JWT-secured APIs
- Planters and plants in matched sizes, with sizing rules
- A blog of four in-depth posts about the self-moving auto planter, the key product on sale
- Mock card payments with deterministic declines
- Product insurance, cover activation and a bundled expert check-in
- Insurance claims against active cover
- An AI chatbot for signed-up customers that knows every detail of the planter and its blog posts, as well as the customer's own orders, cover and claims
- Truck delivery scheduling within 150 km of Melbourne
- Date manipulation to fast-forward deliveries, clearly flagged as test data
- Support enquiries and complaints, with email updates

Verdant Staff - https://staff.verdant-v1.testthis.now
- Staff enrolment that mirrors customer sign-up
- Orders, deliveries and customers from your own test sessions
- Support case and insurance claim handling, with every update emailed to the customer
- A second point of view to verify what the shop claims happened

Verdant Warehouse - https://warehouse.verdant-v1.testthis.now
- Sign in with your staff account; each app issues its own token
- Orders allocated to each truck, day by day
- One action: add trucks to a day (up to 99) and watch the schedule respond
- Order numbers are visible across the whole business, order details are not: a deliberately small surface for access-control testing

### GrantWorks, version 1 (live)

https://grants-v1.testthis.now/

A grant-management system for small fictional grants that fund learning about software testing: a regulated, multi-party approval process of the kind found in government, research funding and financial services.

- Sign-up with email verification and mandatory TOTP MFA, enrolled from a QR code
- Grant applications that name a character referee; the referee is emailed a link and must respond before the application is approved
- Payment set-up and bank details once approved, then a remittance advice by email
- Multiple applications per applicant, each moving through its own states
- Webhooks on application events, with a delivery log, a send-test-event button and replay of past deliveries
- A long happy path that suits data-banking patterns, and a realistic target for load testing an approval workflow
- Sign up with any email address, or a testdata.help address when scripts need to read the messages

### Medical Centre, version 1 (live)

An Australian GP practice, Northside Medical Centre, built as a system under test. Connected apps serve patients, reception, clinicians and practice managers, while every outside party (pathology lab, pharmacy, specialist, Medicare, My Health Record) is simulated inside the system and can be driven from a test, immediately or on a schedule. Records follow Australian digital-health standards such as AU Core FHIR and SNOMED CT-AU, and every record expires after 30 days. Never enter real personal or health information.

There are no shared demo logins.
- Staff sign up on the app for their role with their own address at testdata.help, confirm a 6-digit emailed code, and enrol an authenticator app (TOTP). Every sign-in needs email, password and the current authenticator code, and a code cannot be reused.
- Patients are generated: on the patient portal, "Create a new user and reveal login details" makes a complete fictional patient (Medicare number, IHI, address and so on) with a verified login, and shows it on screen. Patients sign in with email and password only.

Apps:
- Launcher - https://mc-v1.testthis.now/ : how staff sign up and how patients are generated, links to every app, the API index, and short health informatics notes written for IT and test professionals.
- Patient portal - https://mc-patient-v1.testthis.now/ : one click creates a complete fictional patient and shows its login details; then book, reschedule and check in, see results and medicines, pay invoices, message the practice, manage consents and see who has accessed the record.
- Front desk - https://mc-reception-v1.testthis.now/ : receptionists sign up here. Appointment book and waiting room, patient registration with Healthcare Identifier lookup, billing and Medicare claiming, reminders, recalls and tasks.
- Clinical workspace - https://mc-clinic-v1.testthis.now/ : GPs, practice nurses and nurse practitioners sign up here and join the appointment book. Consultation notes, coded problems and allergies, ePrescribing with SafeScript checks, pathology orders and the results inbox, referrals, immunisations and My Health Record.
- Practice administration - https://mc-admin-v1.testthis.now/ : practice managers sign up here. Users, roles and capabilities (including resetting a user's authenticator), practitioners, practice settings, the audit log, reports, integration status, a breach register and the 30-day retention dashboard.
- External-party simulator - https://mc-sim-v1.testthis.now/ : simulator operators sign up here. Act as the pathology lab, pharmacy, specialist, Medicare, My Health Record, SafeScript, the Healthcare Identifiers Service and the immunisation register, immediately or on a schedule, and read the email and SMS outbox.
- API - https://mc-api-v1.testthis.now/.well-known/mc-v1.json : JSON API (/api/v1), simulator API (/sim/v1) and a read-only FHIR R4 interface (/fhir/r4) shaped on AU Core, for API, integration and load tests. The index lists every host and route.

Scripted staff sign-up and sign-in with the testdata.help helpers:

    POST https://mc-api-v1.testthis.now/api/v1/auth/staff/signup   {"app":"clinic","role":"gp","email":"gp-<run>@testdata.help","password":"...","givenName":"...","familyName":"..."}
    GET  https://api.testdata.help/v1/mail/pop?address=gp-<run>@testdata.help&wait=20          -> 6-digit code
    POST https://mc-api-v1.testthis.now/api/v1/auth/verify        {"email":...,"code":...}         -> enrolmentToken
    POST https://mc-api-v1.testthis.now/api/v1/auth/mfa/enrol     {"enrolmentToken":...}           -> secret
    GET  https://api.testdata.help/v1/totp/set?key=<runkey>&user=<email>&secret=<secret>
    GET  https://api.testdata.help/v1/totp/get?key=<runkey>&user=<email>                        -> code / nextCode
    POST https://mc-api-v1.testthis.now/api/v1/auth/mfa/activate  {"enrolmentToken":...,"code":...} -> session token
    POST https://mc-api-v1.testthis.now/api/v1/auth/login         {"email":...,"password":...,"totp":<code, or nextCode if code was just used>}

Generated patient: POST https://mc-api-v1.testthis.now/api/v1/auth/generate-patient returns the new patient's details and login.

## How Verdant Dock compares with a typical demo app

- Identity: emailed verification code, mandatory TOTP MFA, password reset, JWT sessions, one staff login with separate per-app tokens (typical demo: username and password, often pre-filled).
- Email: real delivery; use a testdata.help address and read every message through the helper API (typical: none, or faked on screen).
- Text messages: real SMS sent and received; reading them automatically through testdata.help is available to paid clients or with a self-hosted instance (typical: none).
- Payments: mock card processing with predictable declines for negative-path tests (typical: always succeeds).
- Business rules: size matching, insurance, delivery radius, bundled service entitlements (typical: add to cart, check out).
- Time: deliveries and cover progress over days, with a controllable test clock (typical: everything happens instantly).
- Multiple actors: customers, staff and warehouse in three apps acting on the same records (typical: one user, one screen).
- Security surface: a warehouse view that shows order numbers but not orders (typical: nothing worth probing).
- After-sales: support cases raised by email or in-app, insurance claims, both worked by staff with notifications (typical: ends at the confirmation page).
- AI component: a role-scoped chatbot that knows the product and its blog posts in detail; test its facts, boundaries and resistance to prompt injection (typical: none).
- Stability for scripts: versioned hostnames, so published versions do not move under your tests (typical: changes without notice).

## Test helpers

The free testdata.help helper API provides email inboxes, TOTP codes, test data lists, locks, counters and performance checks. No sign-up or key is needed.

- Machine-readable service list: https://api.testdata.help/.well-known/endpoints
- Documentation: https://testdata.help/
- For fully automated runs, sign up with any address at testdata.help and collect the messages with /mail/pop, then store the secret shown during MFA enrolment with /totp/set and generate codes with /totp/get.

## Challenges: test Verdant Dock with an AI assistant

Eight levels, from a first sign-up to a self-seeding run across all three Verdant apps. Every level is meant to be done with an AI assistant, using the testdata.help helper API. Early levels give the prompt, middle levels name the services, and the top levels give only the goal.

Start here:
1. Read the machine-readable service list: https://api.testdata.help/.well-known/endpoints
2. Take the level brief, or the prompt where one is provided.
3. A human reviews, runs and fixes what the assistant writes.

Standard opening prompt:

    Read https://api.testdata.help/.well-known/endpoints and use those services wherever they help. Write a [UI, API or performance] test script for Verdant Dock level [N]: [paste the level brief]. Use a unique run code for everything you create, and explain which helper endpoints you chose and why.

### Level 1 - Sign up (Shop; prompt provided)

Automate a complete customer sign-up, including the emailed verification code and mandatory TOTP enrolment.

    Read https://api.testdata.help/.well-known/endpoints. Write a UI based test script that signs up a new customer at https://shop.verdant-v1.testthis.now. Use /lists/codes for a unique run code and /names/get for the customer's name, with an email address at testdata.help. Read the verification email with /mail/pop. When MFA enrolment shows the secret, store it with /totp/set and use /totp/get for the code. Save the email, password and TOTP user with /lists/push under my run key.

Done when: the script finishes logged in, and the account is saved for the next level.

### Level 2 - Log in and log out (Shop; prompt provided)

Reuse a saved account, prove you are logged in, then prove you are not.

    Using the same helper API, take a saved account with /lists/random and log in with a code from /totp/get. Confirm the account page shows the customer's name, then log out. Add tests for a wrong password, a wrong TOTP code and a code that has already been used.

Done when: Back and refresh after logout do not bring the session back, and every negative case has a clear expected result.

### Level 3 - Make a purchase (Shop; hints: /lists/import, /mail/pop, /lists/vars/set)

Buy each planter size with a matching plant, pay by mock card, and confirm the order on screen and by email. Include a declined payment and a password reset.

Done when: one data-driven test covers every size, plus a declined payment that leaves the cart and order in a sensible state.

### Level 4 - Across time, then claim (Shop; hints: /lists/vars/set, /lists/vars/get, /mail/pop)

Insure a planter and a plant, schedule delivery, and use date manipulation to move forward. Check the 150 km delivery rule, cover activation, the expert check-in, and lodge a claim, including one made before cover starts.

Done when: the whole timeline is verified in one run, and the date resets at the next login.

### Level 5 - The back office (Shop + Staff; hints: /mail/send, /mail/pop, /lists/counters/add)

Enrol as staff. Raise a support case in the shop and another by emailing support-verdant-v1@testthis.now, then work both cases and your claim from the staff portal.

Done when: every update produces the expected email, and the shop, the staff portal and the email trail agree, checked through both the UI and the APIs.

### Level 6 - Test the chatbot (Shop + Staff; goal only)

Sign up first: the chatbot is only available to customers. It knows the planter and all four blog posts in detail, so check its product answers against the blog, and its answers about orders, cover and claims against the real data. Then try to trick it into saying something inappropriate, off-brand or simply wrong. Try to make it reveal another customer's details or act beyond your role, including prompt injection hidden in a support case. Measure how long it takes to answer.

Done when: there are repeatable checks that assert facts rather than wording, a response-time gate, and a short report on the boundaries.

### Level 7 - Warehouse and access control (Staff + Warehouse; goal only)

Find your order on its truck and day, add trucks, and test the limit. Then probe the boundary: which tokens work where, and can you see an order that is not yours?

Done when: each finding is reproducible, explained, and discovered only through the apps and their APIs.

### Level 8 - The whole business (Shop + Staff + Warehouse; goal only)

One run that creates all its own data under a unique namespace: customer, staff member, purchase with insurance, delivery, warehouse allocation, claim, email-to-case support and chatbot checks. Everything it creates is registered and cleaned up. The assistant should find the right helper services from the discovery document without being told.

Done when: the suite runs from CI twice at the same time and both runs pass.