Recently, I ran across a test someone wrote to verify functionality offered by a 3rd party framework. This didn’t seem right and here’s why.
When you write a test, you’re basically saying the following: “Friends, Romans, countrymen, lend me your ears. With this test, I am making it known that the software I wrote (or am about to write) will meet the expectation laid out by it.” In other words, you’re making a promise that the code will pass the test.
Implicit in that declaration is the assumption that you can actually make it happen. As in, you have the wherewithal, the access, and the inclination to fix any bug in your software that makes the test fail. Otherwise, why would you write the test?
It’s sort of like putting an item on the menu at a restaurant. If the chef decides to put something on the menu, he is probably assuming that he can actually cook the dish in question, just in case it gets ordered. Otherwise, he’s likely to get some annoyed customers: “What do you mean you don’t know how to make Cioppino? But your description of it sounds so great AND you even have a picture right here in the menu! Come on!”
So, if you write a test for code you don’t control (ex. 3rd party framework), you’re putting an item on the menu you may not be able to cook. All that will do is annoy some customers (i.e. other devs on your team who have to figure out why your tests are failing). Not cool.
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!