mockito 0.11.0

  • README.md
  • CHANGELOG.md
  • Installing
  • Versions
  • --

Mock library for Dart inspired by Mockito.

Pub Build Status

Current mock libraries suffer from specifying method names as strings, which cause a lot of problems:

  • Poor refactoring support: rename method and you need manually search/replace it's usage in when/verify clauses.
  • Poor support from IDE: no code-completion, no hints on argument types, can't jump to definition

Dart-mockito fixes it - stubbing and verifying are first-class citizens.

Let's create mocks

import 'package:mockito/mockito.dart';

//Real class
class Cat {
  String sound() => "Meow";
  bool eatFood(String food, {bool hungry}) => true;
  int walk(List<String> places);
  void sleep(){}
  int lives = 9;
}

//Mock class
class MockCat extends Mock implements Cat{
  //this tells Dart analyzer you meant not to implement all methods, and not to hint/warn that methods are missing 
  noSuchMethod(i) => super.noSuchMethod(i);
}

//mock creation
var cat = new MockCat();

Let's verify some behaviour!

//using mock object
cat.sound();
//verify interaction
verify(cat.sound());

Once created, mock will remember all interactions. Then you can selectively verify whatever interaction you are interested in.

How about some stubbing?

//unstubbed methods return null
expect(cat.sound(), nullValue);
//stubbing - before execution
when(cat.sound()).thenReturn("Purr");
expect(cat.sound(), "Purr");
//you can call it again
expect(cat.sound(), "Purr");
//let's change stub
when(cat.sound()).thenReturn("Meow");
expect(cat.sound(), "Meow");
//you can stub getters
when(cat.lives).thenReturn(9);
expect(cat.lives, 9);

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.

Argument matchers

//you can use arguments itself...
when(cat.eatFood("fish")).thenReturn(true);
//..or collections
when(cat.walk(["roof","tree"])).thenReturn(2);
//..or matchers
when(cat.eatFood(argThat(startsWith("dry"))).thenReturn(false);
//..or mix aguments with matchers
when(cat.eatFood(argThat(startsWith("dry")), true).thenReturn(true);
expect(cat.eatFood("fish"), isTrue);
expect(cat.walk(["roof","tree"]), equals(2));
expect(cat.eatFood("dry food"), isFalse);
expect(cat.eatFood("dry food", hungry: true), isTrue);
//you can also verify using an argument matcher
verify(cat.eatFood("fish"));
verify(cat.walk(["roof","tree"]));
verify(cat.eatFood(argThat(contains("food"))));
//you can verify setters
cat.lives = 9;
verify(cat.lives=9);

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));

Verification in order

cat.eatFood("Milk");
cat.sound();
cat.eatFood("Fish");
verifyInOrder([
  cat.eatFood("Milk"),
  cat.sound(),
  cat.eatFood("Fish")
]);

Verification in order is flexible - you don't have to verify all interactions one-by-one but only those that you are interested in testing in order.

Making sure interaction(s) never happened on mock

  verifyZeroInteractions(cat);

Finding redundant invocations

cat.sound();
verify(cat.sound());
verifyNoMoreInteractions(cat);

Capturing arguments for further assertions

//simple capture
cat.eatFood("Fish");
expect(verify(cat.eatFood(capture)).captured.single, "Fish");
//capture multiple calls
cat.eatFood("Milk");
cat.eatFood("Fish");
expect(verify(cat.eatFood(capture)).captured, ["Milk", "Fish"]);
//conditional capture
cat.eatFood("Milk");
cat.eatFood("Fish");
expect(verify(cat.eatFood(captureThat(startsWith("F")).captured, ["Fish"]);

Spy

//spy creation
var cat = spy(new MockCat(), new Cat());
//stubbing - before execution
when(cat.sound()).thenReturn("Purr");
//using mocked interaction
expect(cat.sound(), "Purr");  
//using real object
expect(cat.lives, 9);   

How it works

The basics of the Mock class are nothing special: It uses noSuchMethod to catch all method invocations, and returns the value that you have configured beforehand with when() calls.

The implementation of when() is a bit more tricky. Take this example:

//unstubbed methods return null
expect(cat.sound(), nullValue);
//stubbing - before execution
when(cat.sound()).thenReturn("Purr");

Since cat.sound() returns null, how can the when() call configure it?

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:

var mockUtils = new MockUtils();
var mockStringUtils = new MockStringUtils();
// Setting up mockUtils.stringUtils to return a mock StringUtils implementation
when(mockUtils.stringUtils).thenReturn(mockStringUtils);

// Some tests

// FAILS!
verify(mockUtils.stringUtils.uppercase()).called(1);
// Instead use this:
verify(mockStringUtils.uppercase()).called(1);

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.

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)).

0.10.0

  • Added support for spy.

0.9.0

  • Migrate from the unittest package to use the new test package.
  • Format code using dartformat

1. Depend on it

Add this to your package's pubspec.yaml file:


dependencies:
  mockito: "^0.11.0"

2. Install it

You can install packages from the command line:

with pub:


$ pub get

Alternatively, your editor might support pub get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:


import 'package:mockito/mockito.dart';
        
Version Uploaded Documentation Archive
2.2.3 Feb 12, 2018 Go to the documentation of mockito 2.2.3 Download mockito 2.2.3 archive
2.2.2 Feb 9, 2018 Go to the documentation of mockito 2.2.2 Download mockito 2.2.2 archive
2.2.1 Nov 16, 2017 Go to the documentation of mockito 2.2.1 Download mockito 2.2.1 archive
2.2.0 Aug 15, 2017 Go to the documentation of mockito 2.2.0 Download mockito 2.2.0 archive
2.1.0 Jul 31, 2017 Go to the documentation of mockito 2.1.0 Download mockito 2.1.0 archive
2.0.2 Mar 10, 2017 Go to the documentation of mockito 2.0.2 Download mockito 2.0.2 archive
1.0.1 Sep 28, 2016 Go to the documentation of mockito 1.0.1 Download mockito 1.0.1 archive
1.0.0 Aug 5, 2016 Go to the documentation of mockito 1.0.0 Download mockito 1.0.0 archive
0.11.0 Sep 14, 2015 Go to the documentation of mockito 0.11.0 Download mockito 0.11.0 archive
0.10.1 May 13, 2015 Go to the documentation of mockito 0.10.1 Download mockito 0.10.1 archive

All 20 versions...

Analysis

This package version is not analyzed, because it is more than two years old. Check the latest stable version for its analysis.