Practise modern testing on systems that behave like the real thing.
AI is accelerating how fast software gets built. The ability to prove that it works end to end has to keep pace. testthis.now hosts deliberately realistic, integrated applications where teams can experiment, learn and practise AI-enabled testing skills, in a safe environment where nothing is real and nothing can be broken that matters.
Delivery got faster. Verification has to catch up.
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
When code arrives faster, every release carries more change. Teams need testing that is automated, repeatable and fast enough to sit in the pipeline, not a phase at the end.
The risk lives between the components
Unit tests generated alongside the code tend to share its blind spots. Real failures hide in the journeys: sign-up, email codes, MFA, payments, fulfilment, and the back office that picks up the pieces.
AI changes the tester's toolkit
Agents that drive browsers, generate test data, read requirements and propose test cases are powerful, but they need direction, guardrails and a human who knows what good evidence looks like.
Skills need a practice field
You cannot learn this on production, and a to-do list or a one-page sign-up form will not teach it. Practice needs state, integrations, rules and consequences, without real customers or real money.
What you can practise here
Every app on testthis.now is a system under test, built to reward the techniques that matter in AI-accelerated delivery.
- AI-assisted test designTurn business rules into scenarios and edge cases with an assistant, then check its work.
- Agent-driven end-to-end automationPoint Playwright, Selenium or an MCP-connected agent at a real multi-step journey.
- Out-of-band stepsAutomate emailed verification codes and TOTP MFA instead of skipping them.
- APIs, tokens and access controlExercise JWT-secured APIs, per-app tokens from one login, and what each app should not let you see.
- Test data strategyCreate, pool, reuse and isolate data so parallel runs never collide.
- Time-dependent behaviourMove the clock forward to test deliveries, status changes and cover periods.
- Cross-application verificationAct as a customer, then confirm the outcome from the staff and warehouse sides.
- Negative and unhappy pathsDeclined payments, expired codes, password resets and support complaints.
- Pipelines and performanceRun suites from CI and put realistic journeys under load.
The apps
Apps are versioned in their hostnames, so a version stays put once published. Scripts written against v1 keep working when v2 arrives alongside it.
Verdant Dock, version 1
A retailer of self-moving auto planters and the exotic plants that live in them. Verdant Dock is a connected business rather than a single screen: 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.
Verdant Shop
- Sign-up with emailed code and mandatory TOTP MFA
- Password reset and JWT-secured APIs
- Planters and plants in matched sizes, with sizing rules
- Mock card payments with deterministic declines
- Product insurance, cover activation and a bundled expert check-in
- Insurance claims against active cover
- An AI chatbot that answers about your 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
- 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
- Ideal for end-to-end checks that cross the customer and back-office boundary
Verdant Warehouse
- 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 security-minded testers: probe the boundary between what is shown and what should stay private
GrantWorks, version 1
A grant-management system for small fictional grants that fund learning about software testing. Where Verdant Dock is about commerce and logistics, GrantWorks is about a regulated, multi-party approval process: the kind of workflow found in government, research funding and financial services, where one application passes through several people, messages and states before any money moves.
GrantWorks
- 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
- A remittance advice emailed at the end of the journey
- Multiple applications per applicant, each moving through its own states
Why it is worth testing
- A second person in the loop: automation has to act as the referee, from an email, before the applicant can continue
- 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: create verified accounts once, then reuse them for many runs
- A realistic target for load testing an approval workflow, not just a login page
- Sign up with any email address, or a testdata.help address when scripts need to read the messages
Why an integrated system beats a simple demo app
Most practice sites are a shopping cart or a sign-up form. They are fine for learning locators, but they cannot teach the problems that stall real automation programmes. Verdant Dock was built to include them.
| Capability | Typical demo app | Verdant Dock v1 |
|---|---|---|
| Identity | Username and password, often pre-filled | Emailed verification code, mandatory TOTP MFA, password reset, JWT sessions, one staff login with separate per-app tokens |
| None, or faked on screen | Real delivery. Use a testdata.help address and read every message through the helper API | |
| Payments | Always succeeds | Mock card processing with predictable declines for negative-path tests |
| Business rules | Add to cart, check out | Size matching, insurance, delivery radius, bundled service entitlements |
| Time | Everything happens instantly | Deliveries and cover progress over days, with a controllable test clock |
| Multiple actors | One user, one screen | Customers, staff and warehouse in three apps acting on the same records |
| Security surface | Nothing worth probing | A warehouse view that shows order numbers but not orders: a safe target for access-control testing |
| After-sales | Ends at the confirmation page | Support cases raised by email or in-app, insurance claims, both worked by staff with notifications |
| AI component | None | A role-scoped chatbot: test its facts, its boundaries and its resistance to prompt injection |
| Stability for scripts | Changes without notice | Versioned hostnames, so published versions do not move under your tests |
That is the difference between rehearsing a click path and rehearsing a release: the same practice run can cover authentication, messaging, money, time and the back office, which is exactly where AI-generated tests most need a knowledgeable human to check them.
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 free testdata.help helper API for email, MFA codes, test data, locks and performance checks. The help fades as you climb: early levels give you the prompt, middle levels name the services, and the top levels give only the goal.
Start here
- Point your assistant at the machine-readable service list: api.testdata.help/.well-known/endpoints
- Give it the level brief, or the prompt where one is provided.
- Review, run and fix what it writes. The result is yours, not the assistant's.
Human-readable documentation is at testdata.help. No sign-up or key is needed.
The standard opening prompt
Sign up
Automate a complete customer sign-up, including the emailed verification code and mandatory TOTP enrolment.
Your job: run it, read it, and remove anything the assistant hard-coded.
Done when: the script finishes logged in, and the account is saved for the next level.
Log in and log out
Reuse a saved account, prove you are logged in, then prove you are not.
Your job: decide whether the assistant's logged-out check actually proves anything.
Done when: Back and refresh after logout do not bring the session back, and every negative case has a clear expected result.
Make a purchase
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.
/lists/import/mail/pop/lists/vars/setYour job: find the size combinations and payment cases the assistant's data file leaves out.
Done when: one data-driven test covers every size, plus a declined payment that leaves the cart and order in a sensible state.
Across time, then claim
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.
/lists/vars/set/lists/vars/get/mail/popYour job: list the time-based rules the assistant did not think to test.
Done when: the whole timeline is verified in one run, and the date resets at the next login.
The back office
Enrol as staff. Raise a support case in the shop and another by emailing support-v1@testthis.now, then work both cases and your claim from the staff portal.
/mail/send/mail/pop/lists/counters/addYour job: define what consistent means for one record seen through the shop, the staff portal and the email trail.
Done when: every update produces the expected email, and all three views agree, checked through both the UI and the APIs.
Test the chatbot
Your AI tests their AI. Check its answers about orders, cover and claims against the real data. 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.
Your job: write assertions on facts, not wording, and decide when a refusal is the right answer.
Done when: you have repeatable checks, a response-time gate, and a short report on the boundaries.
Warehouse and access control
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?
Your job: write the findings report. The AI can find things; the tester decides what they mean.
Done when: each finding is reproducible, explained, and discovered only through the apps and their APIs.
The whole business
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.
Your job: own the design. 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.
A safe place to experiment
Everything here is invented, and it is meant to be poked, automated and occasionally broken.
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. Do not enter real personal information. Generated names, addresses and testthis.now mailboxes work best.
Your data stays with you
Records you create are separated from other visitors' activity. It 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.
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. Full details at testdata.help.