Is generic testing for correct library usage in a wrapper function bad practice?

I hope this question is sufficiently specific for SO. I am in a situation where I wanted to write a wrapper to simplify get-requests often occurring in a project (written in JS) and to generate a single point of change in case of underlying technology-changes. As of now, this wrapper relies on jQuery which I want to change at some point.

The problem I am facing now is how to properly test the wrapper in a good fashion to ensure correctness after the incoming changes. Things I might wanna test is format of successfully resolved responses or cancelability of long-running requests.

So conceptually speaking to me it seems as I would (a.t.m.) want to test if I am correctly using the underlying library and correctly processing the results given to me.

Is this conceptually acceptable or does it suggest that the design in itself is lacking?

(Why do I have this question:

My first approach was to use a mock-server while running the tests to generically intercept requests. Unfortunately, this fails for jQuery (+ mockserver or nock) for some jQuery-internal reasons that I still fail to understand. After that, I thought of mocking the wrapper's internal library calls making the actual request. But to be honest I find that rather unsatisfying as this would couple the test-implementation quite tightly with the actual implementation, as I probably would have to rewrite the mocks when switching to another library (also one of the final points made in the worthwhile https://martinfowler.com/articles/mocksArentStubs.html). As a result, I am asking myself if my approach is per se conceptually broken. )

Hopefully, this was understandable and sufficiently precise.