How to test an application you did not write

Building an application no longer requires knowing how it was built. Teams ship software generated by AI coding tools, assembled on low-code platforms, or delivered by an outside supplier. The result works — until it quietly does not.

The usual advice is to write tests. That advice assumes you understand the codebase well enough to test it, which is exactly the assumption that no longer holds.

Start from the outside

When you cannot reason about the internals, test the thing users actually do. Not “does this function return the right value” but “can someone buy a product.”

This has a useful property: it does not require reading the code at all. You need to know what the software is supposed to do, and you almost certainly do know that, because you asked for it.

Write down your most important flows in plain language:

1. A new visitor can create an account and log in.
2. A returning customer can add an item to the cart and complete checkout.
3. A failed payment shows a clear error and does not create an order.
4. An admin can find an order and issue a refund.

That list is worth more than a large suite of unit tests against code nobody understands.

Rank flows by what breaking them costs

Not every flow deserves equal attention. Sort by the cost of failure:

• Revenue flows — anything involving payment, subscription or checkout.
• Access flows — login, password reset, permissions. Breakage here locks everyone out at once.
• Data-integrity flows — anything that writes records you cannot easily reconstruct.
• Everything else.

Cover the first three properly before you go near the fourth.

Test the failure paths, not just the happy path

Generated code tends to handle the intended case well and the unintended case badly, because the prompt described the intended case.

So test what happens when the card is declined, when a required field is empty, when the same form is submitted twice, when a session expires mid-checkout. This is where software written quickly tends to break.

Re-run them constantly

The reason this matters more for AI-generated and low-code applications is change velocity. When a feature can be regenerated in an afternoon, a test suite that runs once a release is nearly useless. Whatever you use, the tests have to run often enough to catch a regression the day it appears.

Where this leads

The practical obstacle is usually not knowing what to test — the list above is not hard to write. It is that turning that list into automated tests traditionally required an engineer, and the whole reason the application exists is that an engineer was not available.

That gap is what Testmode is built to close: the flows above, written in the same plain English you just used to describe them, run by synthetic users against the real application, with no access to the source code required.