wp-calypso
wp-calypso copied to clipboard
Update/help center e2e
Proposed Changes
- Branch is based of https://github.com/Automattic/wp-calypso/pull/65888
- This PR increases the coverage of the e2e tests
Testing Instructions
- Checkout this branch
- Run yarn command to decrypt e2e secrets
- Run
yarn workspace @automattic/calypso-e2e build && yarn jest specs/support/*
Pre-merge Checklist
- [ ] Have you written new tests for your changes?
- [ ] Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
- [ ] Have you checked for TypeScript, React or other console errors?
- [ ] Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
- [ ] Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
Related to #
This PR does not affect the size of JS and CSS bundles shipped to the user's browser.
Generated by performance advisor bot at iscalypsofastyet.com.
waiting for help center to get enabled in order to proceed
I had a look over the proposed changes and while I have quite a few questions, I'll start with the one that would affect the course of future action the most.
question:blocking - what is the intended scope of coverage for Help Centre specs?
I ask this because E2E tests are often brittle and require significant maintenance and upkeep.
I wrote a bit about this in this P2 but generally, the idea is that we want to be extremely targeted and focused for any new E2E specs.
How does the above relate to this PR?
I think there's a bit too much happening in this PR, and that it might be better for us to ask what are we trying to achieve with this test? and help narrow down the scope.
For instance, I would suggest that this spec:
- use an existing user but with the new Help Centre applied;
- test on Simple site only;
- test a typical flow that user would take.