>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3479610. --> Reported by: [thejimbirch](https://www.drupal.org/user/2507260) Related to !120 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Now that Cypress landed in Drupal CMS, we can add end to end tests for our recipes. Lets add one to the base SEO recipe.</p> <p>After a day of poking at this and thinking about the testing strategy, here's what I think we should do:</p> <p>If we're testing functionality that supports machine readability and performance -- for example, checking that this recipe is adding JSON-LD markup to the breadcrumbs, or enabling CSS/JS aggregation, etc. -- we should use a regular PHPUnit functional test in most cases. They're well-suited to that.</p> <p>If, on the other hand, we're testing UI interactions, particularly complicated ones that involve JavaScript, we should favor Cypress tests. We should not bother with Nightwatch or (especially) PHPUnit's functional JS tests.</p> <p>To find the right balance between speed and isolation, I think that each *.cy.js file should have a <code>before()</code> function that installs a test site on Standard (or another profile), then asserts against that test site in the <code>it()</code> functions. And there should be a single <code>after()</code> function that tears down the test site. Because remember: our components are baseline-agnostic. They need to work independent of the base Drupal CMS recipe.</p>