Dave Donaldson

As someone who enjoys well-written code like it's nobody's business, I get frustrated when I find methods that do more than one thing because to me, a method that *could* perform several actions is not well-written.

For example, awhile back I came across a method named something like CreateUpdateDeleteItem. The name itself contains three verbs (actions for the grammar impaired), and not only that, but it accepts several parameters, a couple of which are used as flags for conditional logic at different places within the method.

The biggest problem with a method like this is testing. The method itself does not subscribe to the Single Responsibility Principle, and thus contains several nested conditional statements, each of which require their own test permutation to make sure all code paths have been accounted for.

Before I got into unit testing a few years ago, I had a much harder time convincing people of the benefits of splitting a method like CreateUpdateDeleteItem into three separate methods (other than "just because"), but with unit tests I have concrete evidence of why it makes sense to do so. It's amazing what happens when you show someone actual tests because at that point it's no longer theory, it's real. And it's usually only then that the light goes off.

So if you find multi-action methods like CreateUpdateDeleteItem, refactor them appropriately. Your tests will thank you.