← All questions

Why one fixture set for ui, api and hybrid, and which of the fixtures are worker-scoped?

2 answers

• Accepted answer

  One test because a hybrid scenario needs both halves at once. Seeding over HTTP and asserting in the browser inside a single scenario is only expressible if the API client and the page are fixtures on the same test object; split them per layer and you are back to writing glue between two runners. An API scenario simply never touches the page fixture, which costs nothing because fixtures are lazy.

  Worker-scoped, resolved once per worker process:

  • sdods — the project and layer selection
  • registry and config — the discovered projects and the resolved configuration
  • env, runDir, harMode
  • auth — the strategy, overridable per project
  • db, userPool, authCache, healHistory

  Per scenario: scenario, apiContext, api, data, user, storageState, heal, pages, shots.

  So a page object may assume the configuration and the healer are ready, and must not assume anything about another scenario, because pages is per scenario.

  You extend the same object in steps/fixtures.ts, and generation imports the test from there, which is why that file path is not negotiable.

  RNanswered by Reeta NandalSDODS team

  Reply

• The practical consequence of pages being per scenario, since it surprises people:

  pages.get(Class) caches one instance per class per scenario. Two steps in the same scenario get the same page object, so a field set in the first is visible in the second. Two scenarios never share one, even in the same worker, so nothing you set leaks sideways.

  Also: your page-object fixtures have to end up on the test that steps/fixtures.ts exports. Chaining extend is fine, but a second test built from a different base gives you a fixture the generated specs cannot see, and the symptom is an undefined step rather than anything that mentions fixtures.

  FManswered by Fiona McAllister

  Reply

Have a different question? Ask it.