This has several advantages:

If the plugin API changes,
you won’t need to update your tests.

You are only testing your own code,
so your tests can’t fail due to behavior of
a plugin you’re using.

You can use the same approach regardless of
how the plugin is implemented,
or even for non-plugin package dependencies.

Mock the plugin’s public API

If the plugin’s API is already based on class instances,
you can mock it directly, with the following caveats:

This won’t work if the plugin uses
non-class functions or static methods.

Tests will need to be updated when
the plugin API changes.

Mock the plugin’s platform interface

If the plugin is a federated plugin,
it will include a platform interface that allows
registering implementations of its internal logic.
You can register a mock of that platform interface
implementation instead of the public API with the
following caveats: