This won’t work if the plugin isn’t federated.

Your tests will include part of the plugin’s code,
so plugin behavior could cause problems for your tests.
For instance, if a plugin writes files as part of an
internal cache, your test behavior might change
based on whether you had run the test previously.

Tests might need to be updated when the platform interface changes.

An example of when this might be necessary is
mocking the implementation of a plugin used by
a package that you rely on,
rather than your own code,
so you can’t change how it’s called.
However, if possible,
you should mock the dependency that uses the plugin instead.

Mock the platform channel

If the plugin uses platform channels,
you can mock the platform channels using
TestDefaultBinaryMessenger.
This should only be used if, for some reason,
none of the methods above are available,
as it has several drawbacks: