Recently, I’ve had a twitter conversation with Kent Beck. He mentioned that he noticed tests running slower – jumping from 1 to 6 seconds. I asked if he noticed an impact, and he said he definitely started running tests less.

First of all, I take off my hat – I’m not sure I would notice a jump like that. But then I usually use MSTest, which its startup time already consumes this period.

The immediate impact is interesting – if that’s what caused Kent to run the tests less, imagine what happens when you have a big suite that runs for minutes.

At that point, Kent modified the code in order to reduce the length of the tests. He decoupled a dependency to make the tests run quicker.

Now I’m in the business of unit testing, which makes tests run much faster – isolated, in memory, etc. But this was, in a long while since I thought about changing code for test performance.

The accumulating savings in time are big. All the seconds you collect to add up, plus you pay less in context switch and flow breakage. The cost is the modifications of the production code for the tests to run faster. It’s a cost you pay now.

Much like unit tests, there’s no immediate visible ROI – you don’t measure the gain in velocity due to tests running quicker. Yet you feel certain that this is a worthy investment.

So optimization for unit test performance is like unit tests.

Q.E.D.