Bug 1815543 added a most-recently-used ordering to the list of browser and profiles in the new Migration Wizard. We should get some automated tests for it written.

I wrote some guidance on how to get a new test set up as browser_test_migrator_MRU_sort_ordering.js. This comment is going to try to lay out a testing strategy. I realize this is a long read - this is likely going to be the most challenging part of the semester for you, Bryan, but I think you can do it!

So one of the issues we're dealing with is that MigrationUtils will return a different set of migrators based on whatever the local operating system is (returning the Safari migrator on Windows doesn't make much sense, for example), and will only return ones for where there's an existing local profile that can be imported from.

This means that writing a test by relying on the list of migrators returned by MigrationUtils is very brittle and sensitive to the environmental conditions that the test is run in.

Thankfully, there's a strategy for dealing with this - and that's to mock out various dependencies that aren't being tested directly so that they execute in a pre-determined way.

The third-party library we often use to do mocking like this in JavaScript is called Sinon: https://sinonjs.org/

You'll need to import Sinon into your test like this: https://searchfox.org/mozilla-central/rev/336ff5573f4b7aa8e981429093c051b3f78237ec/browser/components/migration/tests/browser/browser_do_migration.js#6.

This is the code we're ultimately trying to test: https://searchfox.org/mozilla-central/rev/336ff5573f4b7aa8e981429093c051b3f78237ec/browser/components/migration/MigrationWizardParent.sys.mjs#56-71

Here's the general strategy of what I suggest we do:

0. We need to create a few fake MigratorBase subclasses. This is annoying, but necessary, because we need each of them to have a unique key so that we can differentiate them, and the keys are (currently) static properties, so cannot be overridden per instance. So please create 4 subclasses, very similar to this: https://searchfox.org/mozilla-central/rev/336ff5573f4b7aa8e981429093c051b3f78237ec/browser/components/migration/InternalTestingProfileMigrator.sys.mjs#13-47 (use different keys for each - "test-migrator-1", "test-migrator-2", "test-migrator-3" and "test-migrator-4". You also can skip implementing this function - we don't need it.

1. We're going to stub out and override the MigrationUtils.availableMigratorKeys getter so that it always returns this Array:

["test-migrator-1", "test-migrator-2", "test-migrator-3", "test-migrator-4"]

2. We're then going to create 4 instances of your 4 MigratorBase subclasses, and have MigrationUtils.getMigrator return each of those 4 instances, one at a time, using onCall: https://sinonjs.org/releases/v15/stubs/#stuboncalln-added-in-v18

So onCall(0), return the first instance of the class with key test-migrator-1, and onCall(1), return the one with the key test-migrator-2, and so on.

4. Use Sinon to override getLastUsedDate on each individual instance. Let's have test-migrator-4 have the current date, test-migrator-2 have yesterday, test-migrator-1 have the day before that, and test-migrator-3 have the day before that. That means that, if things are working correctly, despite returning the migrators in the order 1,2,3,4, they should get ordered 4,2,1,3.

5. Use withMigrationWizardDialog in your test to open an about:preferences tab and show the new Migration Wizard. Then, use something like this to access the MigrationWizard element itself.

6. Use wizard.querySelectorAll("panel-list > panel-item"); to get all of the panel items from the list, in the listed order. Then check that their IDs are in this order: test-migrator-4, test-migrator-2, test-migrator-1, test-migrator-3.

Wow, that's a lot! I expect we'll have a lot of back and forth and we might hit some stumbling blocks as we go. That's okay! Just ask when you're stuck or you hit something unclear and we'll sort it out with you.