Introduce unit test coverage for both ComponentSource plugins (Block + SDC)

SingleDirectoryComponentTest::testRewriteExampleUrl() is being added in 🐛 Adding the Image component results in a state considered invalid Active .

I wanted to start with this issue but I'm unable to create a Block under XB.

Is there an option within the UI or should be done in a custom code/module?

Thanks!

See the GIF in ✨ Display "Dynamic Components" in top bar popover Active 😊

Hopefully that'll get you started!

See the GIF in #3508326: Display "Dynamic Components" in top bar popover 😊

Oh! there it is :D. Thanks!

Hi @wim-leers,

I've added the first draft of the BlockComponentTest. To do so, I've created a xb_test_block to populate a basic block and I'm testing the plugin id and the cache tags just to see if this is the correct approach for this test. If so, I'll continue adding new tests to it.

Thanks!

This now blocks 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active !

Left a detailed review with pointers for how I’d like to see these unit tests evolve to something more complete. I tried to describe my ideal end goal 😊 — which I failed to do in the issue summary 🙈 Sorry about that!

This is definitely on the right track, but I only now specified in sufficient detail what I consider the end goal. Apologies for not doing that sooner.

That's testing that the XB config entity for that component is not created.
If we want to improve it, we can also use ComponentIncompatibilityReasonRepository to assert the reason why it happens.

See \Drupal\experience_builder\Controller\ComponentStatusController

Tests refactored to @depends to speed them up and make it quicker.

@isholgueras I want to apologize to you! You were eager to jump onto this, and you did so impressively and did lots of great work! 👏

But, I should've provided more direction, because I know the history of how we came to the current state of things. You're brand new to the project, so you couldn't!

So, I've taken everything you've done, kept 80% of it, streamlined it in a way that I believe will scale to all ComponentSource plugins (the 3 that exist today, the upcoming one for "JS components that take over a block plugin's rendering", and all future ones), and did the work to identify the first critical tasks to transplant our historical test coverage that was incredibly SDC-centric and move it into the current multi-component-source-reality:

1. 📌 Move components/sdc_statuses/* SDCs into `xb_test_sdc` module Active
2. 📌 ComponentSource robustness: add `ComponentSourceTestBase::testSettings()` Active
3. 📌 Expand `::getClientSideInfo()` test to all ComponentSource plugins Active
4. 📌 [PP-1] Add `JsComponent` unit test Active

… more issues will be needed. But the goal is to stop testing component source-specific things in ComponentTest, which is solely about the Component config entity. I think we should end with only \Drupal\Tests\experience_builder\Kernel\Config\ComponentTest::testOperations()

Thank you so much for getting us this far along, you helped us make a big jump forward in test clarity!

This unblocked 📌 [PP-1] Failing kernel tests for all ways a component source can fail to render on the server side Active !

And see #17 for 4 other follow-ups :)