Unit Testing Components

[BE-Webdesign]

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:

• [x] autocomplete
• [x] button ( #926 )
• [ ] clipboard-button
• [x] dashicon ( #928 )
• [ ] drop-zone
• [x] dropdown-menu
• [x] dropdown
• [ ] external-link
• [x] form-file-upload
• [x] form-toggle ( #930 )
• [x] form-token-field ( #924 )
• [ ] higher-order ( #931 )
  • [ ] navigate-regions
  • [x] with-api-data
  • [x] with-context
  • [ ] with-fallback-styles
  • [x] with-focus-outside
  • [x] with-focus-return
  • [ ] with-instance-id
  • [x] with-spoken-messages
• [x] icon-button ( #932 )
• [x] keyboard-shortcuts
• [ ] menu-items
• [x] navigable-container
• [x] notice
• [x] panel ( #933 )
• [x] placeholder ( #935 )
• [x] popover
• [ ] responsive-wrapper
• [ ] sandbox
• [x] slot-fill
• [x] spinner ( #936 )
• [x] tab-panel
• [ ] toolbar
• [x] tooltip

Editor Components:

• [x] autosave-monitor
• [ ] block-drop-zone
• [ ] block-inspector
• [ ] block-list
• [x] block-mover ( #980 )
• [x] block-settings-menu
• [ ] block-switcher ( #990 )
• [ ] block-toolbar
• [x] default-block-appender
• [x] document-outline
• [ ] editor-history
• [ ] editor-notices
• [ ] error-boundary
• [x] inserter
• [ ] meta-boxes
• [ ] navigable-toolbar
• [x] page-attributes
• [x] post-author
• [ ] post-comments
• [ ] post-excerpt
• [ ] post-featured-image
• [ ] post-format
• [ ] post-last-revision
• [x] post-pending-status
• [ ] post-permalink
• [ ] post-pingbacks
• [x] post-preview-button
• [x] post-publish-button
• [ ] post-publish-dropdown
• [ ] post-publish-with-dropdown
• [x] post-saved-state
• [ ] post-schedule
• [x] post-sticky
• [ ] post-taxonomies
• [ ] post-text-editor
• [ ] post-title
• [ ] post-trash
• [ ] post-visibility
• [ ] provider
• [ ] table-of-contents
• [ ] unsaved-changes-warning
• [ ] warning
• [ ] word-count
• [ ] writing-flow

Block Components

• [ ] alignment-toolbar
• [ ] autocompleters
• [ ] block-alignment-toolbar
• [ ] block-controls
• [x] block-description
• [x] block-edit
• [x] block-icon
• [ ] color-palette
• [ ] contrast-checker
• [x] Editable ( 😱 )
• [ ] inspector-controls
  • [ ] base-control
  • [ ] checkbox-control
  • [ ] radio-control
  • [x] range-control
  • [ ] select-control
  • [ ] text-control
  • [ ] textarea-control
  • [ ] toggle-control
• [ ] library:
  • [ ] audio
  • [ ] button
  • [ ] categories
  • [ ] code
  • [ ] cover-image
  • [ ] embed
  • [ ] freeform
  • [ ] gallery
  • [ ] heading
  • [ ] html
  • [ ] image
  • [ ] latest-posts
  • [ ] list
  • [ ] more
  • [ ] paragraph
  • [ ] preformatted
  • [ ] pullquote
  • [ ] quote
  • [ ] reusable-block
  • [ ] separator
  • [ ] shortcode
  • [ ] table
  • [ ] text-columns
  • [ ] verse
  • [ ] video
• [ ] media-upload-button
• [x] url-input

[nylen]

It doesn't appear that anyone is pursuing testing too much

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 needs-unit-tests Nylen".

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

[aduth]

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

[BE-Webdesign]

Yeah, I was thinking of using Enzyme. https://github.com/Automattic/wp-e2e-tests is a lot to take in 😅.

What sorts of behaviors should we be testing?

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.

[BE-Webdesign]

Going to breathe some life back into this endeavor, after I touch up meta boxes.

[gziolo]

I updated the list of all components with the actual status. I omitted edit-post which is going to be moved into its own folder soon. This list is huge. @mtias do we want to keep this issue open?

[mtias]

Closing for now.