wp-calypso
wp-calypso copied to clipboard
Site Migration: Add test helper to render steps
Related to #87643
Proposed Changes
- Add initial tests to the site migration plugin install step
- Add a utility to test to simplify the rendering of the test
How it works?
The goal is to have a reliable, fast, and flexible test suite where we can quickly introduce new changes based on the project evolution without running manual tests on every PR.
To reach this goal, we need to follow some principles:
- Render the component in a way that most closely resembles browser rendering.
- Intercept the API requests at the lowest level possible to ensure we pass the required parameters and handle the endpoint answer. Nock is the tool we have now to do it.
- Simulate the user behavior as closely as possible when the user finishes interacting with the component. In this case, I am using navigation. submit` to identify if the user can finish the step.
Testing instructions
Scenario 1: We accidentally introduced a change that breaks our API calls
- Go to the file https://github.com/Automattic/wp-calypso/blob/30c79fb8a40784b88fc7c81084f6ea9fa91cd14e/client/landing/stepper/declarative-flow/internals/steps-repository/site-migration-plugin-install/index.tsx?plain=1#L39 and remove the line we are using to call the endpoint ``/sites/${ siteId }/plugins/migrate-guru%2fmigrateguru
,
- Run the test suite and check if the test suite provides feedback about it.
Scenario 2: Update the code without affecting the tests
- Reset the Scenario 1 changes.
- Wrap the component
h1
https://github.com/Automattic/wp-calypso/blob/30c79fb8a40784b88fc7c81084f6ea9fa91cd14e/client/landing/stepper/declarative-flow/internals/steps-repository/site-migration-plugin-install/index.tsx?plain=1#L68C7-L68C58 with a div `<h1....>- Run the tests and check if they are green.
This PR modifies the release build for the following Calypso Apps:
For info about this notification, see here: PCYsg-OT6-p2
- wpcom-block-editor
To test WordPress.com changes, run install-plugin.sh $pluginSlug add/step-test-helper
on your sandbox.
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:
App Entrypoints (~37 bytes added 📈 [gzipped])
name parsed_size gzip_size
entry-stepper +234 B (+0.0%) +25 B (+0.0%)
entry-main +234 B (+0.0%) +24 B (+0.0%)
entry-subscriptions +126 B (+0.0%) +12 B (+0.0%)
entry-login +126 B (+0.0%) +12 B (+0.0%)
entry-domains-landing +126 B (+0.0%) +12 B (+0.0%)
entry-browsehappy +126 B (+0.1%) +12 B (+0.0%)
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.
Sections (~2091 bytes removed 📉 [gzipped])
name parsed_size gzip_size
home +196 B (+0.0%) +495 B (+0.1%)
scan +181 B (+0.0%) -2 B (-0.0%)
site-purchases -103 B (-0.0%) -29 B (-0.0%)
purchases -103 B (-0.0%) -29 B (-0.0%)
jetpack-search +103 B (+0.0%) +30 B (+0.0%)
backup -92 B (-0.0%) -2 B (-0.0%)
email -90 B (-0.0%) -153 B (-0.1%)
domains -90 B (-0.0%) +2 B (+0.0%)
themes -13 B (-0.0%) -33 B (-0.0%)
theme -13 B (-0.0%) -33 B (-0.0%)
plugins -13 B (-0.0%) +6 B (+0.0%)
marketplace -13 B (-0.0%) -32 B (-0.0%)
jetpack-cloud-plugin-management -13 B (-0.0%) -21 B (-0.0%)
hosting -13 B (-0.0%) -30 B (-0.0%)
checkout -13 B (-0.0%) -4 B (-0.0%)
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.
Legend
What is parsed and gzip size?
Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.
Generated by performance advisor bot at iscalypsofastyet.com.
Just to break the tests modifying the URL (optional)
@gabrielcaires I'm not sure I fully understand what to do here. Can you provide more detail/context on the testing instructions?
Just to break the tests modifying the URL (optional)
@gabrielcaires I'm not sure I fully understand what to do here. Can you provide more detail/context on the testing instructions?
Since it is a PR that is introducing tests, the only suggestion I could think of is to introduce a change in the target code to see if the test is breaking. But it is pretty optional.
Just to break the tests modifying the URL (optional)
@gabrielcaires I'm not sure I fully understand what to do here. Can you provide more detail/context on the testing instructions?
Since it is a PR that is introducing tests, the only suggestion I could think of is to introduce a change in the target code to see if the test is breaking. But it is pretty optional.
It would be helpful if you provided an example 😄
@markbiek I updated the PR description describing the overall approach and with 2 test scenarios.