szczepan faber mockito story (1)

24
Mockito story from the raise of the mocking tools into the era of continuous deployment. by Szczepan Faber

Upload: magda3695

Post on 01-Jul-2015

69 views

Category:

Technology


2 download

DESCRIPTION

.

TRANSCRIPT

Page 1: Szczepan Faber   mockito story (1)

Mockito storyfrom the raise of the mocking tools into

the era of continuous deployment.by Szczepan Faber

Page 2: Szczepan Faber   mockito story (1)

TDD / XP community

Page 3: Szczepan Faber   mockito story (1)

No Getters

Page 4: Szczepan Faber   mockito story (1)
Page 5: Szczepan Faber   mockito story (1)

XP2000

Page 6: Szczepan Faber   mockito story (1)

“Endotesting”

“Using Mock Objects for unit testing improves both domain code and test suites (...)”

Tim Mackinnon, Steve Freeman, Philip Craig

Page 7: Szczepan Faber   mockito story (1)

"A Brief History of Mock Objects"

"(...) many of the steps were manual, or augmented with code generation tools. This turned people off—they couldn't separate the idea from the implementation"

Tim Mackinnonmockobjects.com

JMock

Page 8: Szczepan Faber   mockito story (1)

Elsewhere, sill in 2000

by Tammo Freese

Page 9: Szczepan Faber   mockito story (1)

"EasyMock: Dynamic Mock Objects for JUnit" (2002)

“EasyMock is ideal for often-changing interfaces inside the application, as it handles changes to the interface quite well.”

Tammo Freese

Page 10: Szczepan Faber   mockito story (1)

"EasyMock: Dynamic Mock Objects for JUnit" (2002)

"The only drawback of EasyMock is that tests using it are harder to read than tests using implemented Mock Objects (...)"

Tammo Freese

Page 11: Szczepan Faber   mockito story (1)

"Mock Roles not Objects"OOPSLA 2004

Page 12: Szczepan Faber   mockito story (1)

"Mock Roles not Objects"“Only Mock Types You Own”“Don’t use getters”“Specify as little as possible in a test”“Too Many Mocks”

Page 13: Szczepan Faber   mockito story (1)

"Mock Roles not Objects"About EasyMock: "(...) the simple way of defining expectations often results in over-specified, brittle tests."

Page 14: Szczepan Faber   mockito story (1)

2007/2008

beautiful tests

less brittleness

easy to write

Page 15: Szczepan Faber   mockito story (1)

Qualityshow me your testsand I will know all about the quality of the production code

Page 16: Szczepan Faber   mockito story (1)

Refactoringneat and tidy testsfor poorly designed and architected production codedon’t exist

Page 17: Szczepan Faber   mockito story (1)

TimeoutIf you cannot come up with a failing test in 10 minutestake a step back and continue refactoring.

Page 18: Szczepan Faber   mockito story (1)

PrideTest code is code.Be proud of the code you write.

Page 19: Szczepan Faber   mockito story (1)

Recipe

+

Page 20: Szczepan Faber   mockito story (1)

Mockito popularity9th java library or maybe 4th?

Page 21: Szczepan Faber   mockito story (1)

ProblemI’m obsessed with qualityI coached teamsI preached at conferencesI’m test driven

Every test is neat and fastCoverage is 90%+I release every 2 yearsWhat’s wrong?

Page 22: Szczepan Faber   mockito story (1)

Deliver!

Quality is irrelevantWhat matters is “quality delivered”

Page 23: Szczepan Faber   mockito story (1)

Mockito’s continuous deploymentevery push == new version (not snapshot)release notes and docsautomated release notescan release from a phonerelease in 10 minutes

Page 24: Szczepan Faber   mockito story (1)

To be continued…