Slide 1

Slide 1 text

Mocking Why ? What ? When ?

Slide 2

Slide 2 text

Then the Queen left off, quite out of breath, and said to Alice, "Have you seen the Mock Turtle yet?" "No," said Alice. 
 "I don't even know what a Mock Turtle is." "It's the thing Mock Turtle Soup is made from," 
 said the Queen. —Alice in Wonderland, chapter 9 2

Slide 3

Slide 3 text

Presentation plan Mocking on Android 1. Why,  what  &  when  mocking  ?   2. A  simple  test   3. Tes

Slide 4

Slide 4 text

Why Mocking ? Mocking on Android Most  parts  of  a  soIware  system  do  not  work  in   isola

Slide 5

Slide 5 text

What to mock ? Mocking on Android When testing a component A, we mock the dependencies of A (that are used in each tests). Here, when testing ComputerNextBusinessDay, we would mock NextDayFinder and BusinessDayChecker.

Slide 6

Slide 6 text

When to mock ? Mocking on Android The answer is simple : as soon as you got a dependency. Nevertheless, as you will see, when mocking becomes too complex, it often means that your class should be split and redesigned. Mocking makes testing more complicated. Try to stick to a common/comprehensible structure inside your project’s tests, this will make them much easier to read. 
 Further on, we will see : ‘’GIVEN WHEN TEST‘’ which is a good structure, but not the only one.

Slide 7

Slide 7 text

Warmup : a simple test Mocking on Android demo (branch : sni/mock-workshop). git co -b temp 41cecac

Slide 8

Slide 8 text

General tests advises Mocking on Android • Do not, ever, add logic for a test. You would need to test it… • Use test coverage tools to see how much your code is tested. • Structure your tests • Name your tests well 
 (At Groupon we now use testSomething_should_returnSomethingOrDoSomething_when_thisConditionOrThisConditionApplies) • Always use the same assertion set, do not mix. We use Hamcrest and core matchers. • Do not make tests slow. (>100ms). It kills the team productivity. • Do never use system date, make all tests 100% reproducible

Slide 9

Slide 9 text

Testing a Component Mocking on Android demo (branch : sni/mock-workshop). git co -b temp ed6b8b

Slide 10

Slide 10 text

Testing a Component Mocking on Android Things to do : 1. Test NextDayFinder 2. Test BusinessDayChecker 3. Test ComputerNextBusinessDay

Slide 11

Slide 11 text

Units and Systems Mocking on Android A B C In this case, B and C can be unit tested as they have no dependencies.
 But unit-testing A is not possible as A is indeed a system : 
 A = {A, B, C}

Slide 12

Slide 12 text

How to test a system ? Mocking on Android A B C

Slide 13

Slide 13 text

Using fake dependencies Mocking on Android A B C If we had fake B and fake C, that we fully control, then we could test A as a unit, decoupled from B and C.

Slide 14

Slide 14 text

2 sub problems Mocking on Android A B C There are then 2 subproblems : 1. How to make A use fake B and fake C for tests ? 2. How to create fake B and fake C ?

Slide 15

Slide 15 text

How to make A use fake B and fake C for tests ? Mocking on Android A B C DI to the rescue !!
 (actually, inversion of control)

Slide 16

Slide 16 text

How to make A use fake B and fake C for tests ? Mocking on Android

Slide 17

Slide 17 text

How to make A use fake B and fake C for tests ? Mocking on Android

Slide 18

Slide 18 text

How to create fake B and fake C ? Mocking on Android In the literature, such classes are called Stubs.
 They are fake objects, fully controllable, and their state can be tested.
 Stubs have no limits and can be very complex.

Slide 19

Slide 19 text

Testing a System with Stubs Mocking on Android demo (branch : sni/mock-workshop). git co -b temp 5ffa6f RoboGuice makes it easy to inject stubs. Each test that extends GrouponTestBase can provide its own modules.

Slide 20

Slide 20 text

Mocks ! Mocking on Android demo (branch : sni/mock-workshop). git co -b temp b1fef A Mock Object is a test-oriented replacement for a collaborator. It is configured to simulate the object that it replaces in a simple way. Henri Tremblay, still… Mocks are Stubs made easy. 
 …With some subtile differences.

Slide 21

Slide 21 text

Mocks are statefull Mocking on Android 1. createMock create a mock of a class / interface 2. expect configures mock calls that are expected during a test When all expectations are defined, you have to call replay
 PRIOR TO launching the test.

Slide 22

Slide 22 text

Mocks are statefull Mocking on Android 3. Mock are replayed during a test 4. Mocks can be verified Mock verification has the same value as an assertion. Mocks can be reset between tests to allow orthogonal testing.

Slide 23

Slide 23 text

General mocking advises Mocking on Android • Mock ALL your dependencies. Otherwise you run real code, which is bad : • it appears as covered by tests while it is not. You bullshit yourself. • it slows down tests • it is not a unit test • Learn advanced mocking techniques : • Partial mocking & using final • Captures • If you can’t mock it as you want, it’s wrong.

Slide 24

Slide 24 text

RG makes mocking easier Mocking on Android With RG we automate mock creation for you. Simply annotate the dependencies you wanna mock. demo (branch : sni/mock-workshop). git co -b temp 964bcb

Slide 25

Slide 25 text

RG makes mocking easier Mocking on Android With RG, helpers are provided to replay and verify mocks. All mocks are reset automatically between tests.

Slide 26

Slide 26 text

RG makes mocking easier Mocking on Android With RG, we create a module with all @Mock annotated fields for you.

Slide 27

Slide 27 text

Mocking : Dos and Don’ts Mocking on Android Dos: 1. mock when possible, more than all when the real implementation is costly (DB, network) 2. design classes to be mocked easily (avoid final & static methods) 3. Use DI to inject mocks 4. verify state changing methods Don’ts: 1. overuse mocks. When there are too many things to mock, there is probably a better design. 2. don’t forget to reset mocks 3. don’t forget to replay mocks

Slide 28

Slide 28 text

Mocking on Android Questions ? Comments ?