Embed Size (px)
DESCRIPTION
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.
Citation preview
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?
Evolution Continuous Delivery is a black belt in Continuous Integration C.D. is like C.I. evolved
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
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
Menu
How Mockito does it How Gradle does it How big and famous do it
2007/2008
beautiful tests
less brittleness
easy to write
test code is code proud of the code
Recipe
+
Mockito popularity 9th java library or maybe 4th?
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?
Deliver!
Quality is irrelevant What matters is “quality delivered”
Mockito 1.9.*
time consuming release notes creation rare releases release fear demotivating growing backlog concerned community
Mockito 1.10.*
● time consuming release notes creation ● rare releases ● release fear ● demotivating growing backlog ● concerned community Challenges: ● automation ● quality assurance
Mockito’s model
push == new version (not snapshot) release notes and docs release notes automated can release from a phone ~10 minutes new energy
Tools
Integration
Travis CI and GitHub (via Gradle)
Travis CI can read and write to GitHub OAuth2 protocol Travis CI environment variables encryption GitHub REST API
Travis CI and Bintray
Bintray and jcenter Gradle Bintray plugin Bintray REST API
http://blog.bintray.com
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
Mockito’s continuous delivery model wound’t be possible without...
Gradle’s release model
Release every ~2 months Major version release every 1-2 years Nightly builds Lots of automated validation Very credible tests
Challenges
Fast full feedback cycle from automated checks Huge amounts of automated tests Cross-platform testing Automated performance tests Flaky tests Culprit detection
Patterns
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.
Test selection
Do I need to invoke all available tests to validate my change?
Dry-running a change
How can I ensure that my change does not break the build?
Culprit detection
How to track down a test failure to a commit?
What is the “last known good” version?
Good version
Enterprise dependencies
Does my change breaks components that depend on me?
Perceptual diffs
“The Secret to Safe Continuous Deployment” ~Google developers
Thanks! Continous Delivery is a mindset Start slowly and incrementally Automate more Code is worth zero until released
Szczepan Faber Engineer, coach, consultant
@szczepiq
