OrbitTest Docs
Home / Writing Tests / Test Basics
QA Blog

Writing Tests

Test Basics

Write readable tests with clear setup, action, assertion, and diagnostic structure.

Page6 of 28
Reading timeCalculating
Sections0
Documentation goal: this page is written as practical product documentation, with enough context to help a real QA engineer decide how to use the feature in a maintainable test suite.

Test shape

A readable end-to-end test has a clear name, a short setup, user-facing actions, and assertions that explain the value of the flow. Avoid naming tests after implementation details. Name them after behavior.

Arrange, act, assert

The arrange phase prepares state or opens the page. The act phase performs user-visible actions. The assert phase verifies the outcome the user or business cares about. Keeping that structure visible makes reviews easier.

Failure quality

Every test should fail in a way that gives useful information. Add assertions around meaningful text, route changes, important buttons, or reportable state. A test with no strong assertion is only a script.

test('guest can open pricing page', async (orbit) => {
  await orbit.open('https://example.com');
  await orbit.click('Pricing');

  expect(await orbit.hasText('Choose your plan')).toBe(true);
});

Practical checklist

  • Keep the workflow readable enough that a QA engineer, developer, or product teammate can understand the intent without opening application source code.
  • Prefer user-visible names, stable configuration, and clear evidence over hidden assumptions or brittle implementation details.
  • Run the smallest useful check locally before adding it to CI, then verify that failures produce screenshots, logs, traces, or reports that explain what happened.
  • Review this part of the suite regularly so outdated examples, stale setup, and obsolete workarounds do not reduce trust in the automation.

Common mistakes to avoid

  • Do not add automation only to increase test count. Each page and test should protect a clear user journey, release risk, or debugging need.
  • Do not hide important behavior inside helpers so deeply that the test no longer explains what the user is doing.
  • Do not rely on fixed sleeps when the application can expose a meaningful ready state such as visible text, URL change, element availability, or completed evidence capture.
  • Do not ignore failing artifacts. A report, screenshot, trace, or log entry should feed back into better product code, better waits, or clearer test data setup.

Was this page useful?

Your response is saved in this browser and helps shape the docs experience.