Slide 1

Slide 1 text

Unit Testing Sucks … and it is your our fault

Slide 2

Slide 2 text

Who am I? fiunchinho [email protected]

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

Testing “Testing sucks!” - Everybody

Slide 7

Slide 7 text

Testing

Slide 8

Slide 8 text

Testing

Slide 9

Slide 9 text

Testing Testing don’t suck: tests that suck, suck.

Slide 10

Slide 10 text

We care about clean code

Slide 11

Slide 11 text

... but we forgot something

Slide 12

Slide 12 text

Writing better tests Tips and tricks for writing better tests

Slide 13

Slide 13 text

Subtle Differences #1: Test code is different from other code

Slide 14

Slide 14 text

4 rules of Simple Design Passes its tests Minimizes duplication Maximizes clarity Has no superfluous parts

Slide 15

Slide 15 text

Rules for tests? Trustworthy Express the intent Flexible

Slide 16

Slide 16 text

Tips and Tricks #2: Choose better test names

Slide 17

Slide 17 text

Choose good names I don’t want to read the whole test case to know what is trying to test. Please. Pretty please. Problems

Slide 18

Slide 18 text

What are we testing here?

Slide 19

Slide 19 text

What are we testing here?

Slide 20

Slide 20 text

Tips and Tricks #3: Avoid logic inside tests

Slide 21

Slide 21 text

Avoid logic inside tests Conditionals: You don’t know which path the test will take Loops: you could be sharing state between tests If tests have logic, who test the tests? Problems

Slide 22

Slide 22 text

Avoid logic inside tests

Slide 23

Slide 23 text

Tips and Tricks #4: Highlight the important stuff

Slide 24

Slide 24 text

Be concise Too much information in your tests make them hard to read Think about what details could you leave out Assert messages help us highlight behaviour Problems

Slide 25

Slide 25 text

Assertions Use the name of the test for explaining the feature that you are testing.

Slide 26

Slide 26 text

Assertions Use the name of the test for explaining the feature that you are testing. Then use assert messages to clarify what's the example under test and why is that tested.

Slide 27

Slide 27 text

Highlight the important

Slide 28

Slide 28 text

Highlight the important

Slide 29

Slide 29 text

Tips and Tricks #5: Don’t hide the important stuff

Slide 30

Slide 30 text

Rules for tests Trustworthy Express the intent Flexible

Slide 31

Slide 31 text

Rules for tests Trustworthy Express the intent Flexible

Slide 32

Slide 32 text

Duplication

Slide 33

Slide 33 text

Expressing the intent "The refactoring technique ‘Extract Method’ is not about saving lines of code to make it shorter, but about make the code more readable"

Slide 34

Slide 34 text

Typing isn’t the bottleneck "Programming is not about typing... it’s about thinking" - Rich Hickey

Slide 35

Slide 35 text

Usual suspects Set Up Data Providers

Slide 36

Slide 36 text

Techniques

Slide 37

Slide 37 text

Usual suspects Set Up Data Providers

Slide 38

Slide 38 text

Problems with Set Up Move important code out of sight Now you have to remember that the code was there Since code in setUp is generic for all test cases, you lose context on why is that code there Problems

Slide 39

Slide 39 text

Data Providers

Slide 40

Slide 40 text

Explicit Set Up ™

Slide 41

Slide 41 text

Usual suspects Set Up Data Providers

Slide 42

Slide 42 text

Problems with Providers Tend to make tests more complex The most meaningful parts of the test (input & output) are now outside the test Usually end up more complex than you expected Problems

Slide 43

Slide 43 text

Data Providers

Slide 44

Slide 44 text

Solutions Use Explicit Set Up ™ for the important stuff Don’t mix different test cases in one provider Avoid logic inside providers

Slide 45

Slide 45 text

Tips and Tricks #6: Builders to the rescue

Slide 46

Slide 46 text

Building same objects

Slide 47

Slide 47 text

Building same objects We depend on the stability of the constructor / setter methods. If they change, we are screwed. We are force to pass all the parameters, even if they are not important for the test. Problems

Slide 48

Slide 48 text

Building same objects

Slide 49

Slide 49 text

Building same objects

Slide 50

Slide 50 text

Tips and Tricks #7: Building your own DSL

Slide 51

Slide 51 text

No semantic

Slide 52

Slide 52 text

Single level of abstraction Single Level of Abstraction Principle

Slide 53

Slide 53 text

Single level of abstraction

Slide 54

Slide 54 text

Creating your DSL

Slide 55

Slide 55 text

Creating your DSL

Slide 56

Slide 56 text

Creating your DSL

Slide 57

Slide 57 text

Creating your DSL

Slide 58

Slide 58 text

Tips and Tricks #8: Mocking, the right way

Slide 59

Slide 59 text

Test Doubles

Slide 60

Slide 60 text

Test Doubles

Slide 61

Slide 61 text

Test Doubles Test doubles are objects that we create to help us test our system

Slide 62

Slide 62 text

Test Doubles Dummy Fake Stub Spy Mock

Slide 63

Slide 63 text

Test Doubles Dummy Fake Stub Spy Mock

Slide 64

Slide 64 text

Test Doubles Dummy

Slide 65

Slide 65 text

Dummy

Slide 66

Slide 66 text

Dummy Use the real object unless its instantiation has side effects or is expensive somehow

Slide 67

Slide 67 text

Test Doubles Stub

Slide 68

Slide 68 text

Test Doubles Mock

Slide 69

Slide 69 text

Components Value object Entity Service

Slide 70

Slide 70 text

Test Doubles Avoid test doubles for Value Objects

Slide 71

Slide 71 text

Test Doubles Avoid test doubles for Value Objects Think twice before using test doubles for Entities

Slide 72

Slide 72 text

Command Query Separation Command Query

Slide 73

Slide 73 text

Command Commands change the state of a system but do not return a value

Slide 74

Slide 74 text

Query Queries return a value and don’t change the observable state of the system Free of side effects

Slide 75

Slide 75 text

Test Doubles Use stubs to force a query to return a specific value so you guide the execution path of the test

Slide 76

Slide 76 text

Test Doubles Use stubs to force a query to return a specific value so you guide the execution path of the test Use mocks to assert that a command to another object has been sent

Slide 77

Slide 77 text

Without Test Doubles is this still unit testing?

Slide 78

Slide 78 text

Unit Test Unit test

Slide 79

Slide 79 text

Isolated Test Isolated test

Slide 80

Slide 80 text

Decoupling Don’t modify your tests when refactoring. It would couple the test to the current implementation

Slide 81

Slide 81 text

Tips and Tricks #9: How much testing is enough?

Slide 82

Slide 82 text

How much to test "Write tests until fear is transformed into boredom"

Slide 83

Slide 83 text

How much to test Confidence Communication Success!

Slide 84

Slide 84 text

How much to test Confidence Communication Success!

Slide 85

Slide 85 text

How much to test Confidence & communication are the goals High Code coverage is not a goal: is a side effect

Slide 86

Slide 86 text

#10: Think. Don’t blindly follow rules (like these) Tips and Tricks

Slide 87

Slide 87 text

Everything is a trade-off

Slide 88

Slide 88 text

Conclusions Testing makes you go faster. Throw some love to your tests. If you find yourself going slower, identify why. TDD makes all of this much easier.

Slide 89

Slide 89 text

Jose Armesto @fiunchinho