By default, for all methods that return value, mock returns null.
Stubbing can be overridden: for example common stubbing can go to fixture setup but the test methods can override it. Please note that overridding stubbing is a potential code smell that points out too much stubbing.
Once stubbed, the method will always return stubbed value regardless of how many times it is called.
Last stubbing is more important - when you stubbed the same method with the same arguments many times. Other words: the order of stubbing matters but it is only meaningful rarely, e.g. when stubbing exactly the same method calls or sometimes when argument matchers are used, etc.

By default equals matcher is used to argument matching (since 0.11.0). It simplifies matching for collections as arguments. If you need more strict matching consider use argThat(identical(arg)).
Argument matchers allow flexible verification or stubbing

Verifying exact number of invocations / at least x / never

cat.sound();
cat.sound();
//exact number of invocations
verify(cat.sound()).called(2);
//or using matcher
verify(cat.sound()).called(greaterThan(1));
//or never called
verifyNever(cat.eatFood(any));

Strong mode compliance

Unfortunately, the use of the arg matchers in mock method calls (like cat.eatFood(any))
violates the Strong mode type system. Specifically, if the method signature of a mocked
method has a parameter with a parameterized type (like List<int>), then passing any or
argThat will result in a Strong mode warning:

[warning] Unsound implicit cast from dynamic to List<int>

In order to write Strong mode-compliant tests with Mockito, you might need to use typed,
annotating it with a type parameter comment. Let's use a slightly different Cat class to
show some examples:

It works, because when is not a function, but a top level getter that returns a function.
Before returning the function, it sets a flag (_whenInProgress), so that all Mock objects
know to return a "matcher" (internally _WhenCall) instead of the expected value. As soon as
the function has been invoked _whenInProgress is set back to false and Mock objects behave
as normal.

Be careful never to write when; (without the function call) anywhere. This would set
_whenInProgress to true, and the next mock invocation will return an unexpected value.

The same goes for "chaining" mock objects in a test call. This will fail:

This fails, because verify sets an internal flag, so mock objects don't return their mocked
values anymore but their matchers. So mockUtils.stringUtils will not return the mocked
stringUtils object you put inside.

You can look at the when and Mock.noSuchMethod implementations to see how it's done.
It's very straightforward.

1.0.0

Add a new typed API that is compatible with Dart Dev Compiler; documented in
README.md.

0.11.1

Move the reflection-based spy code into a private source file. Now
package:mockito/mockito.dart includes this reflection-based API, and a new
package:mockito/mockito_no_mirrors.dart doesn't require mirrors.

0.11.0

Equality matcher used by default to simplify matching collections as arguments. Should be non-breaking change in most cases, otherwise consider using argThat(identical(arg)).