Code Farming: Sprouting Some Methods

You probably can’t impose unit testing on a whole system all at once. But you probably can increase the portion of the code under test a little bit at a time. When you’re busy but need to make small changes, consider Sprout Method (59).

I am trying, with only partial success, to apply what I’ve learned in Working Effectively With Legacy Code by Michael C. Feathers.

Feathers is a huge advocate of test-driven development. He puts it out there on page xvi: “Code without tests is bad code.” He defines “legacy code” as, strictly speaking, any code that isn’t already under unit tests. At first it struck me as a funny definition, because obviously lots of code is written today–even by me–without unit tests, and how can it be right to refer to software nobody’s even thought of yet as “legacy”? But for purposes of the book it works.

Continue reading “Code Farming: Sprouting Some Methods”

Mock me to my (inter)face

How can you run tests on something where the “output” is the motion of a sensor arm, or the “input” is a stream of weather data?

I learned an interesting, although in retrospect somewhat obvious, technique from Michael Feathers’s great book, Working Effectively With Legacy Code.

Suppose you have a class that can’t be unit-tested in any automated way because it has side effects or requires user input. Or, in the case of my application, it drives hardware that I don’t actually have readily at hand. NUnit and the like provide input to methods and test the resulting output. How can you run tests on something where the “output” is the motion of a sensor arm, or the “input” is a stream of weather data?

The short answer is that you really can’t, but that shouldn’t stop you from setting up unit tests.

Continue reading “Mock me to my (inter)face”