The Agile Engineering Rules of Test Code

June 13, 2012 · 1 min read

Lots of test code gets written, a lot of it is waste, some of it is well engineered waste.

Companies hire Agile Engineering Coaches because agile engineering is easy to do wrong.

Very easy.

So here's a quick tool you can use for self coaching.

It's what I call, "The Agile Engineering Rules of Test Code" and it's going to act as a sort of table of contents for some future posts.

The Agile Engineering Rules of Test Code

Malcolm Anderson

Test code is not throw away code

Test code is production code

8 questions to determine the quality of your test code

  1. Does the test code have appropriate comments?
  2. Is the test code executed as part of the build?
  3. Every Time?
  4. Is the test code getting refactored?
  5. Does everyone use the same test code?
  6. Can the test code be described as “Well Maintained”?
  7. Can a bright six year old tell you why any particular test failed?
  8. Are the tests independent and infinitely repeatable?
This article is part of the GWB Archives. Original Author: Malcolm Anderson

New on Geeks with Blogs

  • We Won The One Award I Actually Care About

    Full Scale made the Inc. 5000 for the fifth year straight, the 12th listing across my three companies. Here is why the one award you cannot buy is worth stopping for.

  • Your Customers Build the Features Now

    I let a tool I liked sit dead for a year rather than build the features I wanted. An MCP server meant I never had to, and your customers can do the same to your product.

  • Get the Size of a Directory in Linux the Easy Way

    du -sh for the quick answer, ncdu for the cleanup, df for the disk itself: every command for checking directory size in Linux, plus why du and df never agree.

  • Vim Search and Replace: The Ultimate Guide

    One :%s command replaces every match in a file before a find dialog would even open. The Vim substitute patterns worth the muscle memory: flags, ranges, capture groups, and multi-file edits.