Stubject (Stubbing the Subject)

You may occasionally see a test case that uses allow or expect on the same object it’s testing. Sam Phippen refers to this antipattern as the stubject code smell, since you’re stubbing methods on the test subject.^[102]

For example, consider the following code for a discussion forum that sends users a summary of what’s happened over the past day:

Here’s an RSpec example for this class that checks the content of the email. We don’t want to send real email from our specs, so on the highlighted lines we’re mocking out the deliver method. Our version will check that we’re calling it with the right body but not actually send an email:

Alas, this spec exhibits the stubject code smell. We’re faking out the deliver method but testing the real send_daily_summary method on the same object.

Test doubles are intended to help you construct a test environment for a real object. Specs like this one blur the line between the subject and its environment. The temptation to fake out part of an object with allow or expect is a design signal. In other words, it’s a hint that one object has two responsibilities, and might result in a better design if we split it up.

First, we can put the SMTP logic into its own EmailSender class:

This class can then be provided to DailySummary as a collaborator using simple dependency injection:

We’re not suggesting you break up classes like this just to satisfy a “don’t stub the subject” rule. Rather, we’re saying that this guideline has told us something about the code. If we put the mail-delivery logic into its own class, we gain the following benefits:

• We can use EmailSender to send other emails besides daily summaries.
• We can test the SMTP logic independently, apart from any specific email.
• We now have a single place to add other email features such as email subscription preferences.

Once the refactoring is done, we no longer need to fake out methods on DailySummary itself. Instead, we can spin up a verifying double for the EmailSender:

With this change, the boundary between the constructed test environment (the fake EmailSender) and the object we are testing (the DailySummary) is much clearer. A code smell in our specs has given us information we can use to improve our design.

Furthermore, moving away from the partial double allows us to improve the test, too. Maintaining the Arrange/Act/Assert flow helps to keep our tests easy to follow when we return to them months later. Let’s convert the double to a spy so we can restore this flow:

While we could have used the partial double as a spy, it’s more cumbersome, because we would have had to allow the deliver message beforehand to spy on it and stub it out. Moving to a pure double allowed us to use it as a spy with little effort.