Post on 16-Feb-2017
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