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?
I've written in the past that integrated tests are a scam, but that's not what I mean here.
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.
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.
After one of the mob programming sessions I did with RubySteps last year, a viewer singled out this as a valuable piece of advice:
I had intended to write a nice article showing a concrete example of learning tests in action, then something wonderful happened: all the code disappeared.
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.
How do I gain confidence in code that generates HTML, such as tag libraries or view templates?
Well, it depends on what I'm trying to do.
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).
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".