Question 1

How do you prepare test data — what is a factory function?

Accepted Answer

A factory (data builder) is a function that returns a ready-made test object when called: buildUser({ role: 'admin' }). It holds sensible defaults, and the overrides parameter lets you change only the field the test cares about. The advantages: (1) a FRESH object per call — tests cannot corrupt each other's data; (2) the test file shows only what matters to it and hides the rest, so the test reads well; (3) when the product model changes, the fix is in one place. For uniqueness I add a timestamp or random part to the email. An important addition: created data must be cleaned up — I do that in a fixture's teardown.

Question 2

When is retrying in tests acceptable and when is it harmful?

Accepted Answer

Acceptable: for non-deterministic infrastructure operations — a dropped connection, a 502 from an external service, a temporarily unavailable test-data API, a resource that is not ready yet. There a retry shields the test from environment noise rather than from a real problem. Harmful: on assertions checking product behaviour — that turns a regression into a matter of probability and eventually the team stops trusting red tests. The framework-level retries setting follows the same logic: keeping it on in CI is pragmatic, but it must be tracked as a metric — which tests pass only on the second attempt, and why. Close with: "A retry buys time but loses information, so every retry must be visible and investigated."

Question 3

What problems does state shared between tests cause, and how do you prevent it?

Accepted Answer

The symptoms are recognisable: a test passes alone but fails in the suite; results change when the order changes; flakiness explodes once parallelism is enabled. The cause is usually one of three: (1) an object declared at module level that tests mutate; (2) a single shared user account or order; (3) state built in beforeAll and modified by tests. To prevent it: each test creates its own data through a factory and cleans up after itself; shared objects are protected with Object.freeze or readonly; setup moves to beforeEach/fixture level; and where an account is required, each worker gets its own. The way to verify: run the tests in random order with increased parallelism — the problem surfaces immediately.

Question 4

When should you build a helper/abstraction layer, and when should you stop?

Accepted Answer

My criterion is simple: an abstraction is valuable when it reduces duplication and makes the test more readable; it is harmful when built just because it looks elegant. In practice I extract a helper after the third repetition — twice is not yet a pattern. Signals to stop: the helper grows five or more parameters or boolean flags (login(user, pass, true, false)); understanding a test requires opening three files; the helper is used in exactly one place; the failure message no longer explains what broke. My position of principle: in test code readability beats DRY — a little duplication is better than a "clever" abstraction with hidden logic, because the person reading the test is usually not the person who wrote it. The best structure: a thin test file → a page object or API client → small, pure utilities, each layer with one responsibility.

Pattern	Problem it solves	Its risk
Retry wrapper (with backoff)	unstable infrastructure: network, 502s, a test-data service	it can hide a real product bug
Polling / waitFor	an async result invisible in the UI (queue, email, invoice)	a long timeout slows down the whole suite
Data builder / factory	fresh, unique, isolated data for every test	the database fills with junk if cleanup is forgotten
Utility composition	building complex scenarios from small functions	over-abstraction hurts readability
Fixture (at framework level)	setup and guaranteed teardown	hidden dependencies make the test hard to read

Common JS patterns in test code

📚 Sources and documentation