Mockito is intended to help writing cleaner and easier to maintain tests. Many tools and frameworks have similiar goals. Also, there are practices and methodologies focused around writing test code, TDD being the best example. We have the tooling, we have the methodology, we can start writing high quality test code any day (or continue doing it). The next logical step is to fully capitalize comprehensive and stable automated test coverage, and start delivering continuously. We will discuss it based on your experience and my lessons learned from Mockito, Gradle, and corporate environments I worked in from Europe to Silicon Valley.

1. Szczepan Faber
I’m obsessed with quality
I coached teams
I preached at conferences
I’m test driven
Every test is neat and fast
Coverage is 90%+
and I release every 2 years… WTF?

3. Evolution
Continuous Delivery
is a black belt in Continuous Integration
C.D. is like C.I. evolved

4. Mindset not a tool
C.I: keeps software ready
for development and validation
gives quick feedback about the correctness
C.D: keeps software ready
for the release
gives quick feedback about the business value

5. Principles
Every build is a release candidate
Automate
Have quality automated tests
More info:
read the book :)
see Jez Humble’s videos on the web

7. Menu
How Mockito does it
How Gradle does it
How big and famous do it

8. 2007/2008
beautiful tests
less brittleness
easy to write

9. test code is code
proud of the code

10. Recipe
+

11. Mockito popularity
9th java library or maybe 4th?

12. Problem
I’m obsessed with quality
I coached teams
I preached at conferences
I’m test driven
Every test is neat and fast
Coverage is 90%+
and I release every 2 years… WTF?

13. Deliver!
Quality is irrelevant
What matters is “quality delivered”

14. Mockito 1.9.*
time consuming release notes creation
rare releases
release fear
demotivating growing backlog
concerned community

15. Mockito 1.10.*
● time consuming release notes creation
● rare releases
● release fear
● demotivating growing backlog
● concerned community
Challenges:
● automation
● quality assurance

16. Mockito’s model
push == new version (not snapshot)
release notes and docs
release notes automated
can release from a phone
~10 minutes
new energy

17. Tools

18. Integration

19. Travis CI and GitHub (via Gradle)
Travis CI can read and write to GitHub
OAuth2 protocol
Travis CI environment variables encryption
GitHub REST API

20. Travis CI and Bintray
Bintray and jcenter
Gradle Bintray plugin
Bintray REST API

21. http://blog.bintray.com

22. Continuous Delivery
Releasing is fun instead of a chore
Working on a feature or a bug is exciting
Releasing is part of regular routine
“Make releasing boring. No more adrenaline.”
~Jezz Humble

23. Mockito’s continuous
delivery model
wound’t be possible
without...

24. Gradle’s release model
Release every ~2 months
Major version release every 1-2 years
Nightly builds
Lots of automated validation
Very credible tests

26. Challenges
Fast full feedback cycle from automated checks
Huge amounts of automated tests
Cross-platform testing
Automated performance tests
Flaky tests
Culprit detection

27. Patterns

28. Flaky tests
What can we do about flaky tests?
Flaky tests are a part the world
Understand them. Model them. Automate them.
Eliminate the the expensive flaky tests regularly.

29. Test selection
Do I need to invoke all available tests to
validate my change?

30. Dry-running a change
How can I ensure that my change
does not break the build?

31. Culprit detection
How to track down a test failure to a commit?

32. Good version
What is the “last known good” version?

33. Enterprise dependencies
Does my change breaks components that
depend on me?

34. Perceptual diffs
“The Secret to Safe Continuous Deployment”
~Google developers

35. Thanks!
Continous Delivery is a mindset
Start slowly and incrementally
Automate more
Code is worth zero until released
Szczepan Faber
Engineer, coach, consultant
@szczepiq