Developer mind

“OH HAI! The process to perform incremental testing is taking several minutes per iteration. This sucks! Automate this!”

“Automation totally rocks! The process to perform incremental testing is now only about a minute.”

[some period of time lapses]

“OH HAI! The process to perform incremental testing is taking a whole minute per iteration. This sucks! Tune the test harness!”

“Automation tuning totally rocks! The process to perform incremental testing is now a mere 30 seconds!”

[some period of time lapses]

“OH HAI! The process to perform incremental testing is taking a whole half a minute per iteration. This sucks!”

[…]

Lesson: If left to my own devices, I’ll spend more time tuning the testing process than developing the code being tested because it feels more wasteful to do otherwise.

Mockity mock moq

Getting a rare chance to do some serious refactoring and have committed to doing it “right” with TDD. To that end I’ve been introduced to my new friend Moq [1]—a lazy-evaluating object mocking framework.

Abstract your objects to interfaces and then create a new Mock object with the interface as its type… and Bob’s your uncle! From here you can stub out your interface object to return whatever values are useful for you when contriving unit tests. All the not-useful stuff? Just let it go since lazy evaluation means the mocked object won’t give a damn so long as you don’t invoke them.

The amount of time saved going this route? ALL OF THE TIMES! Enough I can skip out briefly to tell you all about this goodness and still have developed an OptionsManager framework that is fully covered by unit tests.

See, I do love my job sometimes.

[1] http://code.google.com/p/moq/