Problem/Motivation

There are two invalid tests in core/modules/migrate/tests/src/Unit/MigrateSourceTest.php. Both testCount() and testCountCacheKey() contain the following code:

    // Mock the cache to validate set() receives appropriate arguments.
    $container = new ContainerBuilder();
    $cache = $this->createMock(CacheBackendInterface::class);
    $cache->expects($this->any())->method('set')
      ->with($this->isString(), $this->isInt(), $this->isInt());
    $container->set('cache.migrate', $cache);
    \Drupal::setContainer($container);

Per the comment at the top, the intent is to validate that a cache entry is set with particular arguments. But the expectation for the set() function is any(), which implicitly means that it's valid if set() is never called. As it turns out, that's what happens.

The problem is that the functions call getSource() (in one case multiple times) which creates a container with a different cache service. This overrides what the test functions are trying to do.

This was discovered in the course of working on #3569422: Convert expectation-less test mocks to stubs - Migrate modules where calls to any() are being removed.

Steps to reproduce

Change the any() to atLeastOnce() and run the tests. The tests will throw errors because set() is never called.

Proposed resolution

  • getSource() will continue to set a default stubbed cache service.
  • The functions that want to validate a specific interaction with the cache will now override the service with a mock object.
  • Move the assertions for checking that the cache is being set to the right place within the test functions.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3572915

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

dcam created an issue. See original summary.

dcam’s picture

benjifisher’s picture

It is almost bed time, so I cannot think hard about this ...

Maybe it is just an inaccurate comment: replace "receives appropriate arguments" with "does not receive inappropriate arguments".

Those code blocks are pretty old (2015 and 2016). It would not be surprising if the tested code has changed since the tests were added.

For the record, it looks like most of the two code blocks in question was added in these issues:

dcam’s picture

I haven't been able to figure it out yet. set() should be called during both tests. That code path works when the source is configured with ['cache_counts' => TRUE]. SourcePluginBase::getCache() is called and returns the mocked CacheBackendInterface. I thought maybe the with() statement was causing the problem. set() only takes two parameters, but the with() attempts to set three. But removing it didn't do any good. The test still failed when the any() was changed to atLeastOnce().

dcam’s picture

Oh, of course. The tests create a container with a cache service. But then they call getSource() multiple times which creates a different container with a different cache on each call.

dcam’s picture

Status: Active » Needs review

The key was to move the assertion for checking that the cache is being set to the right place within the test functions. getSource() will continue to set a default stubbed cache service. The functions that want to validate a specific interaction with the cache will now override the service with a mock object.

dcam’s picture

Issue summary: View changes
smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Bug Smash Initiative, +Needs Review Queue Initiative

From what I can tell this is a good update, specifically looking at $cache->expects($this->once()) which proves the set.

Going to go on a limb

longwave’s picture

Version: main » 11.x-dev
Status: Reviewed & tested by the community » Fixed

Good news that the stub conversion is picking up these sorts of errors that we would not spot otherwise, it is worth the pain in the long run!

Committed and pushed b607c8697db to main and 8486ae5d24a to 11.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • longwave committed 8486ae5d on 11.x
    test: #3572915 Invalid tests in MigrateSourceTest
    
    By: dcam
    By:...

  • longwave committed b607c869 on main
    test: #3572915 Invalid tests in MigrateSourceTest
    
    By: dcam
    By:...

Status: Fixed » Closed (fixed)

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