[php vigo][talk] unit testing sucks ( and it's your fault )

Post on 16-Feb-2017

220 Views

Category:

Engineering

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Unit Testing Sucks… and it is your our fault

Testing

“Testing sucks!”- Everybody

Testing

Testing

Testing

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

We care about clean code

... but we forgot something

Writing better tests

Tips and tricks for writing better tests

Subtle Differences

#1: Test codeis differentfrom othercode

4 rules of Simple Design

Passes its tests

Minimizes duplication

Maximizes clarity

Has no superfluous parts

Rules for tests?

Trustworthy

Express the intent

Flexible

Tips and Tricks

#2: Choose better test names

What are we testing here?

Choose good names

I don’t want to read the whole test case to know what is trying to test.

Please.

Pretty please.

Problems

What are we testing here?

Tips and Tricks

#3: Avoid logic inside tests

Avoid logic inside tests

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

Tips and Tricks

#4: Highlight the important stuff

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

Assertions

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

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.

Highlight the important

Highlight the important

Tips and Tricks

#5: Builders to the rescue

Building same objects

Building same objects

We depend on the stability of the constructor / setter methods. If they change, we are screwed.

We are forced to pass all the parameters, even if they are not important for the test.

Problems

Building same objects

Building same objects

Tips and Tricks

#6: Building your own DSL

No semantic

Single level of abstraction

Single Levelof Abstraction Principle

Single level of abstraction

Creating your DSL

Creating your DSL

Creating your DSL

Creating your DSL

Tips and Tricks

#7: Don’t hide the important stuff

Rules for tests

Trustworthy

Express the intent

Flexible

Rules for tests

Trustworthy

Express the intent

Flexible

Duplication

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"

Typing isn’t the bottleneck

"Programming is not about typing... it’s about thinking"

- Rich Hickey

Usual suspects

Set Up

Data Providers

Techniques

Usual suspects

Set Up

Data Providers

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

Data Providers

Explicit Set Up ™

Usual suspects

Set Up

Data Providers

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

Data Providers

Solutions

Use Explicit Set Up ™ for the important stuff

Don’t mix different test cases in one provider

Avoid logic inside providers

Tips and Tricks

#8: Mocking, the right way

Test Doubles

Test Doubles

Test Doubles

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

Test Doubles

Dummy

Fake

Stub

Spy

Mock

Test Doubles

Dummy

Fake

Stub

Spy

Mock

Test Doubles

Dummy

Dummy

Dummy

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

Test Doubles

Stub

Test Doubles

Mock

Components

Value

objectEntity Service

Test Doubles

Avoid test doubles for Value Objects

Test Doubles

Avoid test doubles for Value Objects

Think twice before using test doubles for Entities

Command Query Separation

Command

Query

Command

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

Query

Queries return a value and don’t change the observable state of the system

Free of side effects

Test Doubles

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

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

Without Test Doubles

isthis stillunit testing?

Without Test Doubles

What’s aunit?

Unit Test

Unit test

Isolated Test

Isolated test

Decoupling

Don’t modify your tests when refactoring.

It would couple the test to the current implementation

Tips and Tricks

#9: How much testing is enough?

How much to test

"Write tests until fear is transformed into boredom"

How much to test

Confidence

Communication

Success!

How much to test

Confidence & communication are the goals

High Code coverage is not a goal: is a side effect

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

Tips and Tricks

Everything is a trade-off

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.

Jose Armesto @fiunchinho

top related