Add section about integration testing to testing docs #49454
Conversation
glendaviesnz
added
the
[Type] Developer Documentation
glendaviesnz
requested review from
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
glendaviesnz
force-pushed
the
add/integration-test-docs
branch
from
113eac2
to
f317d96
Compare
| @@ -290,7 +290,30 @@ test('fires onChange when a new value is typed', async () => { | |||
| }) | |||
| ``` | |||
|
|
|||
| ### Integration testing | |||
There was a problem hiding this comment.
The content is mostly about testing blocks, so I wonder if the title should be more specific
| ### Integration testing | |
| ### Integration testing for block UI |
Or alternatively, keep this as the main header for the section, and move the block specific content under a subheader ('Testing a block's user interface').
There are other integration tests in the codebase (the full-content ones that check for block markup regressions), so it might be good to link to the docs for those from here (I believe there's a README in the folder).
There was a problem hiding this comment.
Have changed the heading. The only other readme I could find around integration testing related to the native file testing.
There was a problem hiding this comment.
|
|
||
| Integration testing is defined as a type of testing where different parts are tested as a group. In this case, the parts that we want to test are the different components that are required to be rendered for a specific block or editor logic. In the end, they are very similar to unit tests as they are run with the same command using the Jest library. The main difference is that for the integration tests the blocks are run within a [`special instance of the block editor`](https://github.com/WordPress/gutenberg/blob/trunk/test/integration/helpers/integration-test-editor.js#L60). | ||
|
|
||
| The advantage of this approach is that the bulk of a blocks editor functionality, block toolbar and inspector panel interactions, etc. can be tested without having to fire up the full e2e test framework. This means the tests can run much faster and more reliably. It is recommended that as much of the editor functionality as possible should be covered with integration tests, with e2e tests only used for interactions that require a full browser environment, eg. file uploads, drag and drop, etc. |
There was a problem hiding this comment.
| The advantage of this approach is that the bulk of a blocks editor functionality, block toolbar and inspector panel interactions, etc. can be tested without having to fire up the full e2e test framework. This means the tests can run much faster and more reliably. It is recommended that as much of the editor functionality as possible should be covered with integration tests, with e2e tests only used for interactions that require a full browser environment, eg. file uploads, drag and drop, etc. | |
| The advantage of this approach is that the bulk of a block editor's functionality (block toolbar and inspector panel interactions, etc.) can be tested without having to fire up the full e2e test framework. This means the tests can run much faster and more reliably. It is recommended that as much of the editor functionality as possible should be covered with integration tests, with e2e tests only used for interactions that require a full browser environment, eg. file uploads, drag and drop, etc. |
Small typo here.
It is recommended that as much of the editor functionality as possible should be covered with integration tests
The "It is recommended" part might be a bit strong out of the blocks, considering the approach hasn't been very widely tested yet. 🤔
Maybe the language can be softened, but still propose writing integration tests first.
There was a problem hiding this comment.
Changed the wording to "It is suggested that as much of a block's UI functionality as possible is covered with integration tests, with e2e tests used for interactions that require a full browser environment, eg. file uploads, drag and drop, etc." - is that softened enough do you think?
There was a problem hiding this comment.
Sounds good, thanks for updating it!
What?
Adds documentation to cover new integration testing option added here.
Why?
So people willl know about it.
How?
Wrote it all by myself, no ChatGPT was harmed in the production of this text.
Testing Instructions
Read, and proof.