Unit Testing Components #641
Comments
BE-Webdesign
added
the
[Type] Question
I'd still like to see a rule that we don't merge new code until it has tests. Generally I'm of the opinion that the more automated testing, the better. In fact I've considered changing my name to "James Unit-testing components (and refactoring them so that they can be more easily tested) would be extremely valuable and we would love your help with it. Build time should not be a consideration in making this decision. Integration testing of actual flows would also be very valuable; however, these tests do slow things down quite a bit. Prior art from Calypso: https://github.com/Automattic/wp-e2e-tests |
|
What did you have in mind for component testing? What sorts of behaviors should we be testing? I'm very open toward something like Enzyme, with an emphasis on shallow render testing. I don't think there's a performance worry here (per your note on slower CI build). We already create a fake DOM context in our test bootstrap: https://github.com/WordPress/gutenberg/blob/master/bootstrap-test.js |
|
Yeah, I was thinking of using Enzyme. https://github.com/Automattic/wp-e2e-tests is a lot to take in 😅.
I think testing rendering with default state, and basic state changes is a good place to start. Testing the editor components as well first would be good as they are not changing as frequently as the block components. That way as the block API changes we will know whether or not our components are breaking at least, (hopefully). I don't know if we will want to use the Full DOM as well to keep track of focusing. |
Adds basic button component tests. Covers cases where the tag name or other properties are conditionally rendered. Related to progress on #641. This PR adds the components directory to the list of entry points configured for tests by webpack.
Adds basic rendering dashicon unit tests. Related to #641. The Dashicon should not render when an icon is not provided.
Adds basic FormToggle component tests. Covers cases where the tag name or other properties are conditionally rendered. Related to progress on #641. This introduces Enzyme and the react-test-renderer library as dev dependencies. **Testing Instructions** Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic to ensure tests fail as they should.
Adds basic withFocusReturn HOCtests. Covers cases dealing with the handling of the focus. Related to progress on #641. Adds an extra conditional to match if the body is focused the active elment should become the one bound to the HOC, this is necessary as in the HTML DOM spec it is not supposed to be possible to have `! document.activeElement` ever be true. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic to ensure tests fail as they should. Verify disposable focus returning still works.
Adds basic IconButton component tests. Related to progress on #641. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic to ensure tests fail as they should.
BE-Webdesign
added
[Type] Automated Testing
Adds basic Panel component tests. Related to progress on #641. Covers the Panel, PanelHeader, and PanelBody components. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change component logic to ensure tests fail as they should.
Adds basic withFocusReturn HOCtests. Covers cases dealing with the handling of the focus. Related to progress on #641. Adds an extra conditional to match if the body is focused the active elment should become the one bound to the HOC, this is necessary as in the HTML DOM spec it is not supposed to be possible to have `! document.activeElement` ever be true. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic to ensure tests fail as they should. Verify disposable focus returning still works.
Adds basic IconButton component tests. Related to progress on #641. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic to ensure tests fail as they should.
Adds basic Panel component tests. Related to progress on #641. Covers the Panel, PanelHeader, and PanelBody components. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change component logic to ensure tests fail as they should.
Adds basic Spinner component tests. Related to progress on #641. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change component logic to ensure tests fail as they should.
Adds basic Placeholder component tests. Related to progress on #641. Adds an extra conditional to make testing easier to prevent an element that eventually renders to null from sticking in the tree when the icon prop is not present. Testing Instructions Run npm i && npm run test-unit ensure tests pass. Change component logic to ensure tests fail as they should.
Adds basic Toolbar component tests. Related to progress on #641. **Testing Instructions** Run npm i && npm run test-unit ensure tests pass. Change component logic to ensure tests fail as they should.
Adds tests for the BlockMover Component. Related to progress on #641. The tests ensure that the callbacks render properly depending on whether the block isFirst or isLast.
These tests are related to progress on #641. They handle all instance methods and any conditional rendering logic. **Testing Instructions** Verify that registering of blocks is indeed cleaned up and that tests pass.
Adds tests for the BlockMover Component. Related to progress on #641. The tests ensure that the callbacks render properly depending on whether the block isFirst or isLast.
These tests are related to progress on #641. They handle all instance methods and any conditional rendering logic. **Testing Instructions** Verify that registering of blocks is indeed cleaned up and that tests pass.
|
Going to breathe some life back into this endeavor, after I touch up meta boxes. |
Adds tests for the BlockMover Component. Related to progress on #641. The tests ensure that the callbacks render properly depending on whether the block isFirst or isLast.
gziolo
added
the
Good First Issue
|
I updated the list of all components with the actual status. I omitted |
|
Closing for now. |
Would unit testing components be of value to the project? It doesn't appear that anyone is pursuing testing too much, maybe that would be a good place for me to be productive? Negatives is it will slow down our CI build and as things change it will slow down PRs, but we could do the component testing separately and eventually streamline it into the CI, so we don't have those kind of project flow problems, until things are more stable.
If you add tests to a component please check the matching box off and edit the list item to feature a # link to the Pull Request that added the initial tests.
Here is a list of components to be tested:
Generic Components:
Editor Components:
Block Components
The text was updated successfully, but these errors were encountered: