Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "Refactoring to Patterns"] [Main Index] [Next entry: "RtP in the Wild"]

Ashcroft in Context
Friday, August 27, 2004

The last few weeks have seen some exciting new developments on my current project. The combination of Obie and Aslak on the project gave birth to a new codehaus project. Ashcroft is a SecurityManager meant to enforce that certain behaviors (like file I/O) are not occurring during unit test execution. So why would anyone want something like Ashcroft looking over their shoulder?

Let me try to put Ashcroft in context.

Imagine that you believe strongly in test-driven development. Imagine you inherit a sizeable code base. Imagine that the unit test suite that exercises that code base takes over 10 minutes. That's about 9 minutes and 53 seconds too long, and the delayed feedback you will get as you cycle through red, green, refactor is going to be painful. Your number one priority is getting that test suite running fast. You are suspicious about why the test suite takes 10 minutes...

Enter Ashcroft. You set up Ashcroft in IntelliJ and re-run your test suite. Wow, that runs much faster now! But you get about 453 CantDoThat exceptions and your test suite fails miserably. Ashcroft is imposing its values...er, providing feedback to you. Use this feedback to refactor your tests (you'll probably want to use mock objects). When Ashcroft is happy, your test suite will run very, very fast.

One side effect of using Ashcroft is that it encourages you to create explicit boundaries between unit tests and other kinds of tests.

Powered by Greymatter