@christopherfujino any suggestions on the best way to write tests for this?

I think I want to verify that the call to FakeDevice.startApp() was passed platformArgs that contain a multidex bool, or that the Runner's startApp() was called with multidexEnabled: true/false, but I've not been able to set this up well enough to check that (RunCommand creates Daemon and calls appDomain startApp() which creates a HotRunner).

I think I probably want to add a HotRunnerFactory to AppDomain (similar to the attach test has) but since all the classes in between are constructed directly by calling their constructors, I think it'll mean changing a bunch of things in between I was hoping for a second opinion!

Sorry, I don't have a better idea than this. @GaryQian do you have any ideas?

@GaryQian any thoughts on the above? :)

I had to re-create my fork to fix a dependabot bug which closed this, but I'm still interested in this. I believe this change fixes the issue being reported at Dart-Code/Dart-Code#3837, but I don't know of a reliable way to test these parts of the code (specifically, testing the command line flag makes it down into these classes).

@GaryQian can you take a look at this and how Danny can test it?

Hey sorry for being slow on the reply. The question being asked is primarily within the domain of tooling testing, and unfortunately I don't have too much insight on the best way to test it. The fix itself for passing the multidex flag LGTM though.

My testing for the multidex feature was primarily end-to-end integration tests and unit testing particular methods.

Apparently re-creating my fork disconnected this PR from it. I've re-raised this at #101689.