commit | 64a81acfa76947638f105a862b905d3073616ee9 | [log] [tgz] |
---|---|---|
author | deimon <fibulwinter@gmail.com> | Thu Jan 29 21:21:52 2015 +1100 |
committer | deimon <fibulwinter@gmail.com> | Thu Jan 29 21:21:52 2015 +1100 |
tree | b084419f11a6cd4ff1689077f7906ac29509fa08 | |
parent | bf672ea7a23e4262e940798e8d36b2c48ee01461 [diff] |
Removed references to super which prevent use Mock as mixin. https://github.com/fibulwinter/dart-mockito/issues/2
Mock library for Dart inspired by Mockito.
Current mock libraries suffer from specifing method names as strings, which cause a lot of problems:
Dart-mockito fixes it - stubbing and verifing are first-class citisens.
import 'package:mockito/mockito.dart'; //Real class class Cat { String sound() => "Meow"; bool eatFood(String food, {bool hungry}) => true; void sleep(){} int lives = 9; } //Mock class class MockCat extends Mock implements Cat{} //mock creation var cat = new MockCat();
//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.
//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.
//you can use arguments itself... when(cat.eatFood("fish")).thenReturn(true); //..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.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.eatFood(argThat(contains("food")))); //you can verify setters cat.lives = 9; verify(cat.lives=9);
Argument matchers allow flexible verification or stubbing
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));
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.
verifyZeroInteractions(cat);
cat.sound(); verify(cat.sound()); verifyNoMoreInteractions(cat);
//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"]);