>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3581696. --> Reported by: [benstallings](https://www.drupal.org/user/210009) Related to !8 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>No tests!</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p> File structure</p> <p> migrate_source_queue/tests/<br> src/<br> Unit/<br> QueueIteratorTest.php<br> QueueItemDeleteSubscriberTest.php<br> QueueSourcePluginTest.php<br> Kernel/<br> QueueSourceMigrationTest.php</p> <p> Unit Tests</p> <p> Unit tests mock all dependencies and test logic in isolation. These are fast and don't need a Drupal bootstrap.</p> <p> QueueIteratorTest (extends UnitTestCase)</p> <p> This class implements Iterator and Countable by wrapping Drupal's queue. The tricky part is that getQueue() calls \Drupal::queue() statically, so you'll<br> need to set up the Drupal container mock.</p> <p> Tests:<br> - count() returns the value from QueueInterface::numberOfItems()<br> - valid() claims an item and returns true when an item is available<br> - valid() returns false when claimItem() returns false<br> - valid() injects source ID keys as top-level properties on the claimed item (this is the key behavior that makes Row validation pass)<br> - current() returns the claimed item cast to array<br> - current() returns null when no item is claimed<br> - key() returns the item_id of the current item<br> - key() returns null when no current item<br> - next() clears the current item so the next valid() call claims a new one<br> - rewind() releases the current item and nullifies the queue so a fresh queue is obtained on next access<br> - rewind() does nothing when no queue or item exists<br> - getQueue() calls createQueue() on first access<br> - getQueue() calls garbageCollection() when queue implements QueueGarbageCollectionInterface<br> - getQueue() does NOT call garbageCollection() when queue doesn't implement that interface</p> <p> QueueItemDeleteSubscriberTest (extends UnitTestCase)</p> <p> This is straightforward &mdash; it's a small event subscriber.</p> <p> Tests:<br> - getSubscribedEvents() returns POST_ROW_SAVE mapped to onPostRowSave<br> - onPostRowSave() calls deleteItem() on the source plugin when source is a Queue instance<br> - onPostRowSave() does nothing when the source plugin is NOT a Queue instance (e.g., a SQL source)</p> <p> For the "does call deleteItem" test, you'll need to mock MigratePostRowSaveEvent, the migration, and the source plugin. The source plugin mock should be a<br> mock of the Queue class specifically so the instanceof check passes.</p> <p> QueueSourcePluginTest (extends UnitTestCase)</p> <p> The Queue source plugin has the most logic. Testing it in isolation requires mocking SourcePluginBase internals (migration, id map, etc.), which is doable<br> but involved.</p> <p> Tests for fields():<br> - Returns base fields (data, item_id, created) when no custom fields configured<br> - Merges associative field array (e.g., ['name' =&gt; 'The name']) into base fields<br> - Merges sequential field array (e.g., ['name', 'email']) into base fields via array_flip</p> <p> Tests for isArrayAssociative() (protected, test via fields() behavior or reflection):<br> - Returns true for ['key' =&gt; 'value']<br> - Returns false for ['a', 'b', 'c']</p> <p> Tests for getIds():<br> - Returns the keys configuration value directly</p> <p> Tests for __toString():<br> - Returns the queue_name configuration value</p> <p> Tests for deleteItem():<br> - Gets the queue by name from the row's queue_name property<br> - Constructs an object with item_id and calls QueueInterface::deleteItem()</p> <p> Tests for prepareRow():<br> - Extracts configured fields from the data source property and sets them as individual source properties on the row<br> - Non-field properties are temporarily nulled during hash calculation (verify by checking that parent prepareRow is called while non-fields are null, then<br> they're restored after)<br> - Calls deleteItem() when parent prepareRow() returns false<br> - Calls deleteItem() when needsProcessing() returns false<br> - Does NOT call deleteItem() when row needs processing</p> <p> Tests for needsProcessing() (protected, test via prepareRow() behavior or reflection):<br> - Returns true when id map is empty<br> - Returns true when row needs update<br> - Returns true when above high water<br> - Returns true when row changed<br> - Returns false when none of the above conditions are true</p> <p> Tests for initializeIterator():<br> - Returns a QueueIterator instance with correct queue name and key names</p> <p> Kernel Tests</p> <p> Kernel tests boot a minimal Drupal and let you test with real services.</p> <p> QueueSourceMigrationTest (extends KernelTestBase)</p> <p> This tests the full integration: a migration definition using the queue source, processing items through the migrate pipeline.</p> <p> Setup:<br> - Enable modules: migrate, migrate_source_queue, system<br> - No entity schemas needed since we're testing the source side, not the destination<br> - Create a migration definition programmatically or via config</p> <p> Tests:<br> - End-to-end: add items to a Drupal queue, run a migration with source: queue, verify items are claimed and processed<br> - Items are deleted from the queue after successful row save (event subscriber integration)<br> - Items that don't need processing (duplicate/unchanged) are deleted during prepareRow()<br> - Queue garbage collection runs when the iterator initializes<br> - rewind() releases claimed items back to the queue (important for migration rollback/restart scenarios)<br> - Empty queue results in zero rows processed<br> - Multiple items are processed in sequence (claim, process, delete, claim next)</p> <p> The kernel test is the most valuable because it validates the three classes working together: QueueIterator claims items, Queue source plugin processes<br> rows, and QueueItemDeleteSubscriber cleans up after save.</p> <p> Priority order for implementation</p> <p> 1. QueueItemDeleteSubscriberTest &mdash; simplest class, easiest to test, builds momentum<br> 2. QueueIteratorTest &mdash; core iteration logic, moderate complexity from the static \Drupal::queue() call<br> 3. QueueSourcePluginTest &mdash; most logic but also most mocking overhead<br> 4. QueueSourceMigrationTest (kernel) &mdash; highest value, tests the real integration</p> <p> Notes</p> <p> The QueueIterator::getQueue() static call to \Drupal::queue() is the main testability challenge. In unit tests, you'll mock the container. In kernel<br> tests, the real queue service is available. If contributing upstream, it might be worth proposing that QueueIterator accept a QueueFactory via constructor<br> instead &mdash; that would make it much easier to test and is a cleaner DI pattern.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>Write the tests and make an MR.</p>