As you could read in my initial “Don’t Test…” post, I’m against too many test cases. Here’s another thing you shouldn’t be testing.

There’s this pattern in Ruby of extracting a value into a method:

mail(from: from_email, (...) )

def from_email
  "no-reply@bartek.com"
end

The method is degenerated to only provide some data. This level of granulation could be very useful in some cases. What I wanted to talk about is the temptation of unit test those methods:

expect(from_mail).to equal("no-reply@bartek.com")

Just don’t. It’s way too defensive an approach in my opinion. What’s the value of that test? Essentially, it’s a typo check. This approach deserves a huge “meh” from me.

In my eyes it’s very close to this:

expect("no-reply@bartek.com").to equal("no-reply@bartek.com")

Mostly those methods are private. As I stated in my previous post, you shouldn’t do that anyway.

I agree it could be useful to make sure that nobody pushed a typo, but not in unit test. This is not what unit tests are for. You can still catch the typo:

  • in integration tests:
some_service.call(user) 

expect(mail_adapter).to have_received(:deliver).with(from: "no-reply@bartek.com", (...)

Note that in this context the email address is not data anymore – it’s a part of the output.

  • in code review

This topic touches the test coverage problem too. You could unit test that method but it wouldn’t bring any true value unless it’s used properly in further context.

There are other sheer data providers, think config files. Those shouldn’t be tested as well, actually, how do you even imagine it? You made the data configurable for a purpose – it’s supposed to be easily changed. There’s no need to change it in such a dummy unit test code too.

There’s very little that you could easily read from the production code. Data (unprocessed!) are one of those things. This is one of those rare cases when a test would probably be more time costly than manual look up.