Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

When you are coding, how often do you run your unit test suite? Once a day? Once an hour? Once a minute? Could you even run the suite once a minute if you wanted to? Project Background


Ashcroft is named after the current attorney general of the USA, John Ashcroft, who has a reputation for being extremely conservative. Regardless of your personal political leanings, as an agile and test-infected Java developer, we'd like you to consider the benefits of adhering to strict, almost draconian, limits on what you allow yourself and your fellow team-members to code into your unit tests.

We should clarify, right up front, that these restrictions apply only to unit tests and not system tests or intergration tests, which are also of great importance to the success of any project. However, your unit tests, one for each class in your codebase, should be clean, decoupled from one another and ultrafast. You should be able to run thousands of unit tests and get your green bar in a few seconds. Achieving that kind of unit testing performance takes major discipline on the part of the developer, and Ashcroft helps keep you in on the straight-and-narrow path, by failing tests which stray from best practices.


Only in Subversion for now: svn:// (doesn't work yet)

In the meanwhile you can try the attached jar at the bottom of this page...


Ten Commandments of Unit Tests

  1. I am the class being tested. Thou shalt not test any other class but me.
  2. Thou shalt write isolated tests
  3. Thou shalt not access files during unit tests
  4. Thou shalt not write two tests which depend upon each other

there are more of these to come... we are currently soliciting feedback


Kent Beck about Singletons: "How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead." Test Driven Design By Example (2003) - Beck

Remember, the most severe restrictions often lead to the most creative solutions.


  • No labels