Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Testing nock–client integration issues

See original GitHub issue

The more I read issues like #26 and https://github.com/nodejitsu/mock-request/issues/4 and try to understand why nock is implemented the way it is, the more I wonder if we ought to keep a battery of integration tests using various http clients.

These tests could be used to validate new releases, help client library authors detect quickly when they’ve made changes that break nock, and be a place where bug test cases can be created using nock + whichever version of the test library exhibits the problem.

We’ve validated nock in relation to request libraries through unit tests, though as we’ve discussed that approach is completely unwieldy and should be removed. Those wide-bracket tests do not help us understand why our code does what it does. They don’t even really prevent regressions in the underlying behaviors. Newer versions of those libraries may not still exhibit the exact behavior that triggered the bug, and of course that doesn’t mean the bug is gone.

In general, our approach should be to isolate the bug and put a test around the specific behavior that’s causing the problem, and add comments and references pointing to the standard that show why we do it that way.

That said, if new nock – or a new client library with old nock – breaks people’s tests, it would be good to know about it before developers spend a lot of time tracking the problems down.

So while I think it’s pretty essential that we remove the tests that use, e.g. restify-clients and superagent, I’m not completely convinced that we can reasonably walk away from client libraries. The supermajority of http code in node will go through one of those libraries, and I think that means, for the sake of the nock ecosystem, that we ought to test them.

Part of me is concerned that, when things do break, the problems will manifest far enough downstream from the library authors and in ways that are extremely difficult to track down. Nock isn’t exactly known for being easy to debug. People will open issues here and I feel like there will still be a vast gulf between their problem and something we can act on.

Would having a repo of automated integration tests of client libraries at various versions be a good complement to the unit tests that live here?

I’m open to being convinced otherwise…