Should unit testing be used in prototypes?

No, a prototype that one developer changes and clicks through after every change does not need unit tests, because each failure shows on screen at once. Unit test a calculation only when its result decides whether the project goes ahead.

Should a proof-of-concept application have automated tests?

A proof of concept that answers one technical question and is then thrown away needs no automated tests; check its result by hand against a known case. If it will grow into the product, test the paths you keep before the first real user.

Should I use TDD when prototyping?

Do not use test-driven development to protect a prototype whose design changes daily, because the tests break at every redesign. Tests written to find a design are a design technique, and the framework does not count their value.

When should a prototype get tests?

A prototype should get tests on the day it gets its first real user, real money or real personal data, because its failures then reach people who do not watch the screen. Start with the shortcuts you listed while prototyping.

Should I test a prototype?

Verdict

Do not write automated tests for a prototype that only you change and click through after every change; list each shortcut you take, and add tests on the day the prototype gets its first real user.

Why

Blast radiusinternal
Change frequencyconstantly
Detectabilityimmediately
Reversibilitytrivial
Test costmoderate

I do not write automated tests for a prototype, meaning code built in days to show an idea to my team and then thrown away. Detectability is immediately: a prototype has a few screens, I click through them after every change, and a broken one appears at once. Reversibility is trivial, because the data is fake. Blast radius is internal, since a failure costs a clumsy demo, and Change frequency is constantly, because the design changes daily. Test cost is moderate, because each test takes about an hour and breaks at the next redesign, and rule R8 gives Do not test.

When the decision changes
When	Decision	Why
The prototype produces a number that decides whether the project goes ahead, such as a measured response time	Test minimally: one test that compares the number with a case worked out by hand	Detectability moves to eventually: a wrong number looks plausible on screen
Pilot customers use the prototype with their own data	Test the main path and the likeliest edge cases in CI	Blast radius rises to users, Detectability moves to same-day and Reversibility to with-effort: customers report errors, and their data needs repair
The team ships the prototype as the first version of the product, and its shortcuts compute values that look plausible when wrong, such as imported stock levels or delivery dates	Test those shortcuts and the main path before the first real user	Blast radius rises to users and Detectability moves to eventually: a wrong value raises no error, and no user reports it
The prototype takes real payments on live payment keys	Test mandatory: test the charged amount, refunds and a repeated request before the first payment	Blast radius rises to money and Reversibility to costly: a double charge ends in refunds
A code assistant writes unit tests for the prototype in seconds	Do not test the prototype even so; click through it after each change	Test cost falls to trivial, but Detectability stays immediately and Reversibility trivial

What breaks if you don't test

While the code stays a prototype, I see each failure on the next run. The damage comes when the prototype becomes the product and starts to handle real data with no test behind it. Its shortcuts, such as hardcoded settings or a parser that reads only the sample files, then fail on inputs that nobody clicked through.

What you lose if you over-test

In my practice a prototype's structure changes several times a week, and tests pinned to it break at every redesign. One day of tests in a two-week prototype takes a tenth of its ten working days. A green suite also makes a prototype look ready to ship, which pushes the team toward the promotion that causes the damage.

What to do instead

Before each demo, click through the path you will show.
List each shortcut in the README as you take it.
Agree with the team that the code is a throwaway prototype; Martin Fowler's note on sacrificial architecture makes the case for code you plan to discard.
On the day of the first real user, turn each listed shortcut into a fix and a test, and cover the main path with an end-to-end Playwright test.

Procedure and references

When the answer changes

A number from the prototype decides whether the project goes ahead.
Someone other than you uses it between your changes and finds failures later than you would.
It gets real users, real money or real personal data.

Real incident + Code example

The prototype that became the importer

On an e-commerce project I worked on, I built a two-week prototype that imported supplier price lists from CSV files. I ran it on three sample files after every change and read the prices on screen, so it needed no tests. The buying team liked it, and it went live the next sprint with the same code. The parser removed commas as thousands separators, which matched every sample file. A month later a German supplier sent 12,50 for 12.50 euros, the importer stored 1250, and 300 products went on sale at a hundred times their price. Nobody buys a garden hose for 1,250 euros, so nobody complained; the buying team noticed nine days later, when that supplier's sales fell to zero.

The missing test belonged to the day of promotion. After the fix, the parser takes a decimal separator per supplier, and two pytest tests pin both formats:

from decimal import Decimal

def parse_price(raw: str, decimal_sep: str) -> Decimal:
    thousands_sep = "." if decimal_sep == "," else ","
    return Decimal(raw.replace(thousands_sep, "").replace(decimal_sep, "."))

def test_comma_decimal_supplier():
    assert parse_price("12,50", decimal_sep=",") == Decimal("12.50")

def test_dot_decimal_supplier():
    assert parse_price("1,250.00", decimal_sep=".") == Decimal("1250.00")

FAQ

Should unit testing be used in prototypes?: No, a prototype that one developer changes and clicks through after every change does not need unit tests, because each failure shows on screen at once. Unit test a calculation only when its result decides whether the project goes ahead.
Should a proof-of-concept application have automated tests?: A proof of concept that answers one technical question and is then thrown away needs no automated tests; check its result by hand against a known case. If it will grow into the product, test the paths you keep before the first real user.
Should I use TDD when prototyping?: Do not use test-driven development to protect a prototype whose design changes daily, because the tests break at every redesign. Tests written to find a design are a design technique, and the framework does not count their value.
When should a prototype get tests?: A prototype should get tests on the day it gets its first real user, real money or real personal data, because its failures then reach people who do not watch the screen. Start with the shortcuts you listed while prototyping.