MockSettings has been introduced for two reasons.
Firstly, to make it easy to add another mock setting when the demand comes.
Secondly, to enable combining together different mock settings without introducing zillions of overloaded mock() methods.

Method Detail

extraInterfaces

Specifies extra interfaces the mock should implement. Might be useful for legacy code or some corner cases.

This mysterious feature should be used very occasionally.
The object under test should know exactly its collaborators & dependencies.
If you happen to use it often than please make sure you are really producing simple, clean & readable code.

name

Specifies mock name. Naming mocks can be helpful for debugging - the name is used in all verification errors.

Beware that naming mocks is not a solution for complex code which uses too many mocks or collaborators.
If you have too many mocks then refactor the code so that it's easy to test/debug without necessity of naming mocks.

If you use @Mock annotation then you've got naming mocks for free! @Mock uses field name as mock name. Read more.

spiedInstance

Specifies the instance to spy on. Makes sense only for spies/partial mocks.
Sets the instance that will be spied. Actually copies the internal fields of the passed instance to the mock.

As usual you are going to read the partial mock warning:
Object oriented programming is more or less about tackling complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.

However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.

Enough warnings about partial mocks, see an example how spiedInstance() works:

serializable

Configures the mock to be serializable. With this feature you can use a mock in a place that requires dependencies to be serializable.

WARNING: This should be rarely used in unit testing.

The behaviour was implemented for a specific use case of a BDD spec that had an unreliable external dependency. This
was in a web environment and the objects from the external dependency were being serialized to pass between layers.

serializable

Configures the mock to be serializable with a specific serializable mode.
With this feature you can use a mock in a place that requires dependencies to be serializable.

WARNING: This should be rarely used in unit testing.

The behaviour was implemented for a specific use case of a BDD spec that had an unreliable external dependency. This
was in a web environment and the objects from the external dependency were being serialized to pass between layers.