Skip to content

Fix flaky tests caused by colliding factory slugs - #357

Merged
Cannonb4ll merged 1 commit into
mainfrom
fix/flaky-factory-slugs
Sep 28, 2026
Merged

Cannonb4ll merged 1 commit into
mainfrom
fix/flaky-factory-slugs

Conversation

@Cannonb4ll

Copy link
Copy Markdown
Member

Problem

ViewItemTest > A user with admin access can render a private item page that has no associated project failed now and then in CI with a 302 instead of 200.

The factories for Item, Project, Board and Changelog generated slugs with $this->faker->word, which picks from a list of about 180 lorem words. ViewItemTest's beforeEach already creates an item that belongs to a project. When the test's own item got the same slug, ItemController::show (where('slug', ...)->firstOrFail()) resolved the project item and redirected to its project page.

Reproduced locally by running the test in a loop:

{"id":1,"slug":"dolorem","project_id":1}
{"id":2,"slug":"dolorem","project_id":null}
→ 302 to /projects/recusandae/items/dolorem

Fix

Use $this->faker->unique()->slug() for the slug in all four factories.

Verification

  • Before: the test failed after 14–137 runs
  • After: 300 runs of ViewItemTest with 0 failures
  • Full suite passes (287 tests)

Factories generated slugs with faker->word, which picks from a small
lorem word list. When two records in one test got the same slug, lookups
by slug could resolve the wrong record (e.g. ViewItemTest redirecting to
another item's project page and returning 302 instead of 200).
@Cannonb4ll
Cannonb4ll merged commit be4fe36 into main Sep 28, 2026
4 checks passed
@Cannonb4ll
Cannonb4ll deleted the fix/flaky-factory-slugs branch September 28, 2026 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant