Unit tests for 3rd-party libraries

Question

I'm working on my first real-world Rails project. So far, I'm mostly mashing up functionality from 3rd-party libraries. There's a lot of great ones out there, and that's great.

I'm wondering about whether writing unit tests around these libraries is necessary/useful or not. For example, I just integrated friendly_id around one of my models. Besides installing the gem and adding it as a project dependency, this extent of this integration amounted to:

has_friendly_id :name

It Just Worked, and I barely consider this to be "code I wrote". So what should I be writing by way of tests?

There's two caveats to my question:

1. I'm assuming that all of my 3rd-party libraries have appropriate tests of their own -- and so writing new unit tests directly against those libraries looks like repeating code. (If I had to use a poorly-tested library then I'd be less hesitant to write tests for it.)
2. Under Defect-Driven-Testing, I'd definitely write a test the second I encounter a problem. If the test uncovered a bug in the library, then I'd probably submit the test to the maintainer.

Outside of that though... is there much point to testing 3rd-party code?

Answer 1

No, you shouldn't test 3rd party code, where possible it should sit behind an interface so you can swap out the functionality easily if needs be.
The interface would allow you to use mocks in your code, to mock out calls to the libraries.

Answer 2

It is not the normal practice to unit test some other party's code. Normally, you would trust your upstream dependencies to work correctly.

But that's assuming you actually do trust them. There are all sorts of reasons this should break down.

For one thing, you are stuck with a dependency that is approximately abandoned, with a decent smattering of bugs. As you discover the bugs, write tests that exercise the bugs and exercise workarounds for the bugs.

Another reason might be because the third party keeps changing every damn thing. As you can make time, it's reasonable to add tests for dusty corners that you actually use, because those are the most likely to change on you in a new version.

Obviously either of these cases are really a huge waste of your precious time you could be spending making your app better rather than dealing with something outside your control. If you find you are in need of this kind of testing, you should really be looking for a more trustworthy alternative to that particular dependency.

Answer 3

Never trust third-party libraries. I always write a set of tests I call "sanity checks" for third party libraries, but I only apply it to one model/controller/whatever. So for example if I'm using the acts_as_paranoid gem (which makes database records look deleted but not actually delete them) I'll write a set of tests for just one of the models that uses the extension, and assume it works for the rest of them. This lets me sleep at night knowing that I can update the gem when new releases come out, or even use the "edge" version, and the expected functionality is going to be reliable.