gaybro8777 / automated-testing-playbook Goto Github PK

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:

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

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

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

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

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

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 [email protected]:18F/automated-testing-playbook.git
$ 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 ( https://github.com/18F/automated-testing-playbook/fork )
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.

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.