Updated: Comment #0

Problem/Motivation

We have rudimentary tests for plugin bags, but we should finish them.

Proposed resolution

Expand the unit tests for plugin bags until 100% coverage.
Fix any bugs found along the way.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Comments

tim.plunkett’s picture

Status: Active » Needs review
StatusFileSize
new19.73 KB

This finishes the test coverage, we now have 100%.

While working on this I found a bug in DefaultPluginBag surrounding setInstanceIds(), and PluginBag's set() method. I've fixed those so that the tests pass.

Because we have two subclasses of PluginBag, and also ones dealing with ConfigurablePluginInterface, we now have 3 test classes and base class.

Status: Needs review » Needs work

The last submitted patch, 1: plugin-2137947-1.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
StatusFileSize
new2.9 KB
new22.63 KB

Instead of updating the old test, let's remove it.

neclimdul’s picture

Haven't given this an in depth review but things look good and more tests are always good. Especially when the expose bugs!

damiankloip’s picture

  1. +++ b/core/lib/Drupal/Component/Plugin/DefaultPluginBag.php
    @@ -131,6 +130,15 @@ public function getConfiguration() {
    +    // Ensure the new order matches the original order.
    +    $this->instanceIDs = $this->originalOrder = array_intersect_assoc($this->originalOrder, $this->instanceIDs);
    

    Seems like this change should just live on the PluginBag class?

  2. +++ b/core/tests/Drupal/Tests/Component/Plugin/ConfigurablePluginBagTest.php
    @@ -0,0 +1,97 @@
    +  public static function getInfo() {
    

    We give these docblocks now iirc?

  3. +++ b/core/tests/Drupal/Tests/Component/Plugin/ConfigurablePluginBagTest.php
    @@ -0,0 +1,97 @@
    +    $this->setupPluginBag($this->exactly(3));
    ...
    +    $this->setupPluginBag($this->exactly(3));
    

    It would be nice to assert more about what parameters are passed here but I guess that gets tricky as you are passing this to the base class.

  4. +++ b/core/tests/Drupal/Tests/Component/Plugin/ConfigurablePluginBagTest.php
    @@ -0,0 +1,97 @@
    +    $expected = array(
    ...
    +    $expected = array(
    

    Can these both just share the expected data as a class property?

  5. +++ b/core/tests/Drupal/Tests/Component/Plugin/ConfigurablePluginBagTest.php
    @@ -0,0 +1,97 @@
    +class TestConfigurablePlugin extends PluginBase implements ConfigurablePluginInterface {
    +  protected $configuration = array();
    

    docblocks

  6. +++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultPluginBagTest.php
    @@ -215,4 +123,93 @@ public function testGetConfiguration() {
    +    $expected = array('banana', 'apple');
    +    $config = $this->defaultPluginBag->getConfiguration();
    +    $this->assertSame($expected, array_keys($config), 'After removing an instance, the configuration is updated.');
    

    mh, can we test with assertArrayNotHasKey() or something here?

  7. +++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultSinglePluginBagTest.php
    @@ -0,0 +1,56 @@
    +  public static function getInfo() {
    

    docblock

  8. +++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultSinglePluginBagTest.php
    @@ -0,0 +1,56 @@
    +  protected function setupPluginBag($create_count = NULL) {
    

    docblock

  9. +++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultSinglePluginBagTest.php
    @@ -0,0 +1,56 @@
    +   * Tests the getConfiguration() method with configurable plugins.
    ...
    +  public function testConfigurableGetConfiguration() {
    

    This just tests the get() method.

  10. +++ b/core/tests/Drupal/Tests/Component/Plugin/PluginBagTestBase.php
    @@ -0,0 +1,138 @@
    +   * @var \PHPUnit_Framework_MockObject_MockObject|\Drupal\Component\Plugin\PluginManagerInterface
    ...
    +   * @var \PHPUnit_Framework_MockObject_MockObject|\Drupal\Component\Plugin\DefaultPluginBag
    

    Not sure if I'm right, but I usually switch these the other way round.

dawehner’s picture

+++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultSinglePluginBagTest.php
@@ -0,0 +1,56 @@
+ protected function setupPluginBag($create_count = NULL) {
docblock

+ better typehint.

tim.plunkett’s picture

StatusFileSize
new6.77 KB
new22.56 KB

1) No, both getConfiguration() $this->originalOrder are specific to this subclass.
2) Yep
3) Not sure about this.
4) Updated (they are different, but we can use the initial config and massage it.
5) Turns out its already declared on PluginBase
6) Sure.
7) Done
8) Done
9) Um, no it tests the ConfigurablePluginInterface specific code of getConfiguration
10) Fixed

damiankloip’s picture

Re #9 so this is called from the get() call?

Status: Needs review » Needs work

The last submitted patch, 7: plugin-2137947-7.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review

7: plugin-2137947-7.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 7: plugin-2137947-7.patch, failed testing.

damiankloip’s picture

+++ b/core/tests/Drupal/Tests/Component/Plugin/DefaultSinglePluginBagTest.php
@@ -0,0 +1,56 @@
+  /**
+   * Tests the getConfiguration() method with configurable plugins.
+   */
+  public function testConfigurableGetConfiguration() {
+    $this->setupPluginBag($this->once());
+    $plugin = $this->defaultPluginBag->get('apple');
+    $this->assertSame('apple', $plugin->getPluginId());
+  }

Just read the IRC backscroll, and this clearly is named with GetConfiguration (and in docblock) but only calls get() on the plugin bag, and asserts the Id of that plugin instance. This is the one I was talking about :)

tim.plunkett’s picture

Status: Needs work » Needs review
StatusFileSize
new1.68 KB
new22.55 KB

Oh, there are two testConfigurableGetConfiguration(), one of which is correct. I just copied this around and forgot to rename. Sorry for the confusion.

damiankloip’s picture

Status: Needs review » Reviewed & tested by the community

Ha, no worries :) I think this looks good now.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 8.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.