Comments

We recently ran a legacy code retreat based on your format. People were questioning the value of subclass-to-test in a real world scenario. The best reason I could come up with for myself was that it's a smaller step to separating out responsibilities from a class.

How would you frame the value of subclass-to-test, and in which contexts would you use it?

Read on →

Read on →

Comments

When clients ask me to help them with legacy code it generally takes less than 30 minutes for me to run into a debilitating constructor—a term I use to describe a constructor that does too much. You might think me melodramatic for calling it "debilitating", but these constructors not only slow us down when we try to understand the code, but block our every effort to improve it. These constructors often hardwire a dependency either to some horrifying external resource (a database or a web service end point) or into a framework (even something as "simple" as threads or a lifecycle manager). These constructors also often grow to dozens, and in some extreme cases hundreds, of lines. These constructors kill code bases and, by extension, suck the life out of programmers.

Read on →

Comments

For years I've written about contract tests, and most notably have never had any clear examples of them to share with you. I'd like to change that today.

Read on →

Read on →

Read on →

Comments

I upgraded to Mac OS 10.10 Yosemite and something strange happened with my installations of IntelliJ IDEA. They just disappeared. I still don't know what happened to them. When I tried to reinstall IDEA 13 Community Edition, it crashed on launch.

Read on →

Read on →

Improving Names Comments

Almost everyone starts organizing their tests according to the module (or class or object) that they're testing. If they have a class called Customer, then they have a test case class called CustomerTest and put all the tests for Customer into this one bundle (module, class, describe block, whatever you call it).

Read on →

Surviving Legacy Code Comments

Learn one proven approach to help with the age-old chicken-and-egg problem of "I want to refactor this legacy code, but I'm afraid to change it without tests" and "I want to write tests, but I need to introduce some structure in order to write reasonably-focused tests".

Read on →

Design credit: Shashank Mehta