Last week, I was helping a colleague who was working on a small application. One component was responsible for sending data to a configured recipient. I suggested writing a test to verify that an email was actually sent containing the relevant data in the body. This led to the following discussion:
X: “What? No, I wouldn’t write a test for that.”
Me: “Why not?”
X: “Because we would be testing third-party code.”
Me: “No, we would be testing that our component does what it’s supposed to do.”
X: “Can’t we just mock the mail library?”
Me: “In that case, I’d rather not write a test. I really want to see that it happens.”
X: “I don’t know. It feels wrong.”
Me: “How would you verify that it actually sends the mail then?”
X: “Well, I already installed the mail library, wrote a little test script, spun up a mailhog, and checked that there was a mail in the inbox …”
Me: “… so you kind of did the test I’m suggesting. Manually. One time.”
I guess his approach isn’t that unusual. You write some code to figure out how a new library works, and when you’re confident enough, you integrate it. You save writing a test, because you use a third-party library that just works™. I’m sure it does, but still… I want to see proof.
As I stated in the discussion, it’s not about testing that library. It’s about that our code works as intended, no matter what the implementation looks like. If I upgrade the library to a new version, I want to be sure that it still works. If I switch to a different library, I want to be sure that it works the same as before. Maybe it’s just me, but I really like having that confidence.
So, next time you don’t want to write a test because it’s some lib that just works, plus you just checked it manually: give it a try and automate it anyway. It’s not that hard. (In our case, it was hard. We spent about an hour in some weird jest/javascript hell until the test passed. I really don’t know how people get shit done with javascript)
Top comments (0)