Test coverage overview (always work in progress). Striked-through items are already done.

Basic functionality

  • Basic CRUD operations on entity browser
  • Validators
  • Existing selection
  • Default widget
  • Dynamically generated permissions
  • Dynamically generated routes

Configuration UI

Display plugins

  • iFrame
  • Modal
  • Standalone

Selection display

  • No display
  • Multi step display (not in main ConfigUI class but in its own)
  • View selection display (partly tested in EntityBrowserTest.php)

Widget

  • View
  • Upload
  • Entity form

Individual plugins functionality

Widgets

  • Upload (partly tested in PluginsTest.php)
  • View (partly tested in PluginsTest.php)
  • Entity form

Selection displays

  • Multi step display (partly tested in MultiDisplayTest.php)
  • View
  • No display

Widget selectors

  • Tabs (partly tested EntityBrowserTest.php)
  • Dropdown (partly tested EntityBrowserTest.php)
  • Single

Displays

  • iFrame (partly tested in EntityBrowserUITest.php and PluginsTest.php)
  • Modal
  • Standalone

Field widgets

Integrations

Inline entity form

  • IEF use existing (partly tested in InlineEntityIntegrationTest.php, test full flow: entities are selected, IEF table is automatically reloaded, correct entities appear in it)
  • High prio: Entity browser on a field inside IEF
  • High prio: Entity browser on a field inside nested IEF (2+ levels up)
  • High prio: Entity browser on a field inside IEF, more than one IEF field on the entity (open EB in one, update, open in the other, update, have both open at the same time, update, make sure referenced entities are correct - they are not leaking between fields)

Paragraphs

  • High prio: Entity browser on a paragraph field
  • High prio: Entity browser on a nested paragraph field
  • High prio: Multi value paragraph, more than one value using EB, make sure values are not leaking between them

Comments

slashrsm created an issue. See original summary.

slashrsm’s picture

While working on this I realized (what I already suspected before) that our tests are scattered all around the place. It would be nice to re-organize the structure a bit. Maybe we could use the structure above and groups tests based on that.

mtodor’s picture

I would like to add just few points that could be helpful when tests are written, to have them on mind:

  1. it would be good to introduce traits with provided helpers for entity browser action handling (fe. upload file, reorder list, open modal, select element in view, click use selected, etc.)
  2. for element selectors, best option is to use xpath (I found it most usable during my work on javascript tests). XPath also works fine with multiple drivers (PhantomJS, Selenium)
  3. avoid using values for element selector (fe. click button "Select elements"). Better option is find element with xpath -> then click. That will make tests more valuable, they will still work when someone change name of button in configuration or refactoring, it's also language independent and if such functionality exists in traits it will be usable to implement tests for site that someone builds
  4. for integration tests, it's fine to have custom modules that provides configuration for such tests. It's better then creating everything manually or to have one huge test module with all configuration options
thenchev’s picture

Created issue for paragraphs and will look into it #2826310: Write tests for paragraphs integration

slashrsm’s picture

Issue summary: View changes
marcoscano’s picture

Issue summary: View changes

Updating the IS. It looks like the paragraph tests were done in #2826310: Write tests for paragraphs integration

marcoscano’s picture

Issue summary: View changes

Updated IS. It looks like the first two cases of IEF integration were done in #2764889: Entity Browser widget loses selected images in inline entity form.

oknate’s picture

oknate’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev