What is the difference between cy.fixture() and cy.readFile()?

You're writing a test that needs a list of test users. The data lives in cypress/fixtures/users.json and never changes between runs. Which command do you reach for and why?

A test needs to read a JSON config file that sits outside the project (e.g., /tmp/test-config.json) and might change between test runs. Would you use cy.fixture() or cy.readFile()? What's the practical difference you'd see?

You're debugging a flaky test where cy.fixture('data.json') returns stale data after a previous test mutated the parsed object in memory. Walk me through why this happens and how you'd fix it without switching to cy.readFile().

Your team stores test data in a shared fixtures folder. A new feature requires reading a CSV export that the app generates at runtime into the downloads folder. The file path includes a timestamp. How do you structure this test, and why doesn't cy.fixture() work here?

In a large suite, you notice cy.fixture() calls are slowing down test startup because hundreds of JSON files are being parsed upfront. The data is only needed in a subset of specs. How would you refactor the data loading strategy to improve performance while keeping tests maintainable?

You're migrating from Cypress 9 to 13 and discover that cy.fixture() now caches differently across spec files in parallel mode. A test that worked in serial now fails because it expects a fresh object each run. How do you diagnose this and what's the minimal change to restore isolation?

Your org has 50+ repos with inconsistent test data patterns — some use fixtures, some use readFile, some inline data. You're tasked with defining a cross-team test data strategy that supports parallel execution, deterministic runs, and easy onboarding. What principles do you establish, and how do you enforce them without blocking teams?

A legacy codebase has tests that mutate fixture objects directly (e.g., fixtureData.user.id = 123) causing cascade failures. You can't rewrite all tests at once. Design a migration path that introduces safe defaults, detects mutations in CI, and lets teams opt in to strict mode incrementally.