Making good testing decisions

Slide 1

Slide 1 text

making good testing decisions

Slide 2

Slide 2 text

hi! Engineer @ @ingridepure

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

mission for the day get on the same page testability stubbing vs fakes vs mocking factories over ﬁxtures(…sometimes) some personal preferences make testing more fun save the world!

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

testing Y U SO WEIRD?

Slide 10

Slide 10 text

just don’t make me think.

Slide 11

Slide 11 text

easy readable clear, no hidden tricks, even if it’s rocket science reliable ﬂakiness not accepted. failure   is   failure fast don’t make me wait forever, just tell it to my face

Slide 12

Slide 12 text

keep it simple. start simple.

Slide 13

Slide 13 text

(un) the codebase deterministic factors only clean API API adaptors lazy-driven-design single responsibility principle

Slide 14

Slide 14 text

single responsibility principle deterministic factors only

Slide 15

Slide 15 text

single responsibility principle deterministic factors only

Slide 16

Slide 16 text

Inheritance vs Composition Dependency Injection

Slide 17

Slide 17 text

Client CoffeeShop order OrderProcessor BillingService BeveragesService FoodService etc users are going to use the library's API, not the library's internals process _order validate _order one, clean, simple point of entrance, that returns one thing clean API

Slide 18

Slide 18 text

abstraction layers L1: interfacing with client actions ( imports L2 ) L2: low-level manipulation of data Client Tests you should be able to slice an individual piece of functionality / module at any time

Slide 19

Slide 19 text

what if I told you you can be lazy?

Slide 20

Slide 20 text

lazy-driven-design simple test script written in python clear expectations of what my code WILL do avoid writing your library until you are done deﬁning HOW it will be used NO weird implementation quirks usually no more than 5 lines of code :) i n t e r f a c e i n t e r n a l s

Slide 21

Slide 21 text

internal code can change as much as you want. API is consistent = NO test refactoring

Slide 22

Slide 22 text

test doubles XUnit Test Patterns: Refactoring Test Code  Gerard Meszaros

Slide 23

Slide 23 text

fake. never too late for trick or treat simpliﬁed implementation of a dependency usually doesn’t require a framework store data for later retrieval (cache, databases) no validation of the way the fake is used no validation of the way the fake is used

Slide 24

Slide 24 text

faking a python package

Slide 25

Slide 25 text

stubbing. gimmeh data. provide canned answers to calls made during the test obtain data from a dependency how the data is obtained needs to be not important can record the calls

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

mocking. fake it till you ship it. validating how a dependency is used by the class a mock function call returns a predeﬁned value immediately a mock object's attributes and methods are deﬁned entirely in the test, without creating the real object

Slide 28

Slide 28 text

sanity checkpoints CARE  that your library successfully called the system function to ﬁre your alarm DON’T CARE  experiencing an alarm everytime a test runs ( what if we were testing a rocket launch ) CARE  slow code is out of your tests : network calls and ﬁle systems DON’T CARE  functionally testing 3rd party libraries used in your code.

Slide 29

Slide 29 text

testing without mocks

Slide 30

Slide 30 text

testing with mocks Mock an item where it is used, not where it came from.

Slide 31

Slide 31 text

@mock.patch.object Options: 1. Mock out LogRotationService.rename method itself. 2. Supply a mocked instance in the constructor of LogService

Slide 32

Slide 32 text

@mock.patch.object

Slide 33

Slide 33 text

Creating Mock instances mock.create_autospec method creates a functionally equivalent instance to the provided class. it will raise exceptions if used in illegal ways

Slide 34

Slide 34 text

mock.Mock, mock.MagicMock and auto-spec trick always favour using an auto-spec mock.Mock and mock.MagicMock accept all method calls and property assignments regardless of the underlying API tests will still pass even if the implementation changed

Slide 35

Slide 35 text

mock.Mock, mock.MagicMock and auto-spec trick

Slide 36

Slide 36 text

factories over ﬁxtures (…sometimes)

Slide 37

Slide 37 text

factory-boy fixtures replacement based on thoughtbot’s factory_girl replace static, hard to maintain fixtures with easy-to-use factories for complex objects use objects customized for the current test declare only the fields especially when working with models

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

a framework for your needs unit test frameworks vs functional test framework

Slide 43

Slide 43 text

how to choose? set-up and tear-down multi-level ﬁxtures ( parameters and mark tests as expected to fail ) continue through a test function after failure mark a test as expected minimum boilerplate code easy to parse reporting

Slide 44

Slide 44 text

personal preference py.test powerful named ﬁxtures failure handling and feedback skipping in a very simple way clean and simple asserting assert my_function() == 4

Slide 45

Slide 45 text

@ingridepure Thank you! @ingride