Skip to main content

Product E2E Tests

This guide documents Playwright scenarios for place products: creating or modifying products for the place via the Products tab UI (selector, editor, categories, shortcuts, saving to the place) and related flows such as the bar ticket chain. These are not the same as catalog-template products (IsCatalog, CT, Show All list semantics); those are covered in Catalog E2E Tests. Vocabulary: unpispas-catalog-product-terminology.mdc in the repo rules.

Baseline: Preloaded database. The pw stack reset restores deterministic baseline state before runs. Tests do not depend on previous E2E leftovers.

See E2E Testing (Playwright) for environment setup and how to run tests.

Tests in this guide​

Each heading below (including Setup A) opens a dedicated page in a new browser tab with the full Mermaid flow and implementation details. This hub page keeps only the scenario narratives—the same onboarding-friendly voice everywhere: what you would do in the app, what “good” looks like, then where it lives in the repo.

Setup A (product-create-config)

Shared bootstrap for every test in product-create-config.spec.ts that relies on it: network stub, login, place, Products tab, catalog root, overlays, and opening the type-of-product sheet. Open Setup A — diagram and implementation.

Where it lives: e2e/tests/product/product-create-config.spec.ts — helpers bootstrapCatalog() / openCreateSelector() (see detail page).

shows all product creation types in selector

Imagine a staff member who is already logged in and inside a place. They open the Products tab (place product list) and land on the root grid. They want to add something new, so they tap the usual entry point—the card that invites them to create a product (or the empty-state control when there are no products yet).

The app should answer with a clear question: what kind of thing are you creating? The test is checking that this moment is not broken. After the click, a selector appears with the copy that asks for the product type, and all four expected doors are visible: new group, new product, new generic, and new family. Nothing is saved yet; the story stops at “the user can see every creation path the product editor offers.”

Where it lives: e2e/tests/product/product-create-config.spec.ts — test shows all product creation types in selector.

creates product and enables configuration controls

Same person is back on the Products tab, again with network behaviour stubbed so the app believes it is online. They open the creation selector and this time they choose the straight new product path—not the Bar-style wizard, but the direct “new product” control.

They are dropped into the product editor with a fresh row. They give it a unique name and a price, and they flip the weighted flag. The test is not trying to save to the server or walk through every panel; it wants to know that the screen is actually usable. The typed name and price stay put, the weighted toggle took effect, and the main follow-up actions are there: add category, add shortcut (select), and submit. If those controls are missing or the fields do not hold their values, the person managing the place cannot do their job—so the test fails.

Where it lives: e2e/tests/product/product-create-config.spec.ts — test creates product and enables configuration controls.

opens category editor and shows FIXED configuration inputs

Now the flow goes one level deeper. After opening a new product from the selector, the user fills name and price so the form is real enough to work with. They tap add category. The category editor opens; they name the category and switch its type to FIXED, the mode where you constrain how many options the customer must pick.

The story here is about discoverability of advanced options. For a FIXED category, the UI must surface the min and max fields so staff can set limits. The test stops once those inputs are visible and the submit button for the product is still reachable—again without insisting on a full save or a complete category workflow.

Where it lives: e2e/tests/product/product-create-config.spec.ts — test opens category editor and shows FIXED configuration inputs.

creates full product with category options and quick config

A staff member stubs online mode, creates a new product from the selector, and intends to ship something customers can order with meaningful choices—not just a bare name and price. They add a MULTIPLE category, confirm it with the main Accept control so the editor returns to the product surface, then add one option (enough for the model to expose real choices and unlock preselects). They hit Accept once more so the category option is consolidated before Add quick configuration (preselect) unlocks; they open the shortcut, name it, tick the option checkbox in the shortcut sheet, and apply through the main Accept bar so the shortcut is merged back into the product sheet.

Before they commit the whole product to the place, the UI must already show the category title and the new quick-config row with the names they chose—otherwise the editor is lying. They apply once more to commit, close the panel, and land back on the Products toolbar. The scenario deliberately checks the editor state before the final commit instead of re-searching the grid, because freshly committed rows may not appear in search until the client finishes its sync cycle in some environments. Longer waits, forced clicks, and preselect locators for Playwright are documented on the linked detail page if you are debugging the automation.

Where it lives: e2e/tests/product/product-create-config.spec.ts — test creates full product with category options and quick config.

product chain from catalog through ticket

This last piece is one continuous Playwright test that mimics a longer shift fragment: you work on Products, then you sell at the bar, all in the same browser session and in a fixed order (so it behaves like one story, not seven unrelated checks). If the seed user has no places yet, the flow can create a minimal place with address first; otherwise it opens the first place the way a normal user would.

You sign in, dismiss the cookie banner if it is there, enter the place, open Products, and climb to the catalog home level so you see the product list toolbar with its options—same as if you were checking that the tab is usable before doing real work. From that root, you tap the visible New product / empty-state entry (there can be duplicate grids in the DOM, so the test picks what is actually visible), open the “what type of product?” sheet, confirm the new product path is offered, then Cancel and go back to the grid—sanity only; nothing is saved yet.

Next you edit a real place-owned row: you ignore dimmed catalog templates, group titles, and the “new product” tile, and open the first ordinary product thumb. If the root only shows catalog groups, you drill into E2E Catalog Group A and try again so a row that already exists in the place (for example from earlier catalog tests) can be opened. If the panel opens in summary mode first, you use Edit this product, rename, change the price, save, close, and return to Products.

Then you leave the catalog: switch to tables, open the bar cart, and add a line by choosing a real product heading in the ticket UI (skipping lines that are only prompts). The order should no longer look empty. You tap that kind of heading once more just to confirm the ticket still feels “live” after the add.

After that, you try to clear the ticket: if a delete control for a line is visible, you use it until the product lines are gone and you glance at the header count when the UI exposes it. If this build does not show that button, the test still checks that the order is not empty so the step does not crash on a different layout.

Finally, you should still see something familiar on screen—search near the selector or the product list options—so you know the app did not wander into a dead corner after all that movement. The linked detail page carries the exact Playwright steps and locators if you need to reproduce or debug the automation.

Where it lives: e2e/tests/product/product-chain.spec.ts — test P1-P7 cadena completa de product.