Skip to content
This repository has been archived by the owner. It is now read-only.
A set of principles, practices, idioms, and strategies pertaining to automated software testing and its adoption
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
_data add header, footer, and nav data Mar 20, 2017
assets fix image-path variable Mar 20, 2017
images Convert to use `guides_style_18f` gem Aug 31, 2015
.gitignore Initial commit Jan 28, 2015
.travis.yml Create .travis.yml Feb 26, 2016 Initial commit Jan 28, 2015
Gemfile nix 18f_guides_style Mar 20, 2017
Gemfile.lock one more time Mar 20, 2017 Initial commit Jan 28, 2015 Add "Work In Progress" caveats Feb 12, 2015
go Convert to use `guides_style_18f` gem Aug 31, 2015
index.html Convert to use `guides_style_18f` gem Aug 31, 2015

Automated Testing Playbook

A set of principles, practices, idioms, and strategies pertaining to automated software testing and its adoption.

WORK IN PROGRESS: This material is currently in draft form and under active development. See the GitHub issues page to examine progress.

This guide is a distillation of the principles found in Mike Bland's Unit Testing Perspectives presentation, licensed under CC BY 4.0, based on a high-level outline by Mike and Dr. Robert Read of 18F. It also contains content copied directly from several of Mike's personal blog posts as well as some of his posts on AutoTest Central; both blogs are also licensed under CC BY 4.0.

This playbook is divided into five sections:

Automated Testing Roadmap

A roadmap towards improving a team's automated testing practices, loosely based on Google's Test Certified program.

Principles, Practices and Idioms

Fundamental automated testing and design concepts that inform the craft of writing automated tests and testable code.

APIs and Legacy Systems

Technical impediments to the automated testing of existing systems and how to overcome them.

Rapid Prototyping

When it's OK to get by without writing automated tests, and when it's time to switch gears and add them.

Education and Advocacy

Models and strategies for driving adoption of automated testing throughout a development culture.

Generating the site/hosting locally

You will need Ruby ( > version 2.1.5 ). You may also consider using a Ruby version manager such as rbenv to help ensure that Ruby version upgrades don't mean all your gems will need to be rebuilt.

To run your own local instance:

$ git clone
$ cd automated-testing-playbook
$ ./go init
$ ./go serve

This will check that your Ruby version is supported, install the Bundler gem if it is not yet installed, install all the gems needed by the playbook, and launch a running instance on http://localhost:4000/automated-testing-playbook/.

After going through these steps, run ./go to see a list of available commands. The serve command is the most common for routine development.


  1. Fork the repo ( )
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create a new Pull Request

Feel free to ping @mbland with any questions you may have, especially if the current documentation should've addressed your needs, but didn't.

Public domain

This project is in the worldwide public domain. As stated in CONTRIBUTING:

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

You can’t perform that action at this time.