Is it a best practice or anti-pattern to export mock versions of functions for a library?

Question

Context

We are creating a library that makes an API (HTTP) request to a 3rd party.
During testing we have written mock versions of the functions that make external requests so that we can test the other functionality in isolation.

Question

Should we export the mock version of the functions in the library so that the application using the library can use the mocks in its' own tests to avoid duplicating the mocks?

e.g: (pseudocode)

if (ENV=="test") {
  return MockImplementation
}
else {
  return RealImplementation
}

Is this considered an "anti-pattern" or a "best-practice" when creating a library?

Note: not looking for opinions or flame-war, just some clarity on what to do in practice.
We've tried googling for this, but no relevant result surfaced ... hence the direct question.
If this is not the appropriate place to ask this type of question, where is?

Any insight much appreciated! Thanks!

Additional Detail

We aren't using a mocking library/framework. Our mocks simply return sample response. The application that is consuming the library we are building has to mock the same request because the API in question (Google!) does not have a "test" endpoint. I'm trying not to be too specific so the question is general. The library we've created is intended for general use but we are using it in our own App/project where we are having to duplicate the mocks of the library.

Answer 1

1. I would expect mocks to be in a separate library.
2. Your mocks tie the tester to the specific mocking framework that you have chosen.
3. The tester is usually the one who creates the mocks, as they have the responsibility of setting up the test conditions and assertions.
4. Better APIs usually require fewer mocks. The effort in creating a mock library might be better expended in improving the API.
5. Mocks are closely coupled to the specific software they are testing.

Bottom line? Include the mocks in a separate library if you think they might be useful. But those mocks are mostly useful for testing your library, not their software.

Answer 2

First, I'm using definitions from Gerard Meszaros.

What you are talking about is providing a Test Double so that when a client of your library writes a test, they can use this double instead of real implementation. What you will most probably create is closer to a Fake than a Mock. This means that the test double will be implemented as a normal code, not using any specific mocking/testing framework and will have real implementation, that is usable in fast, isolated automated test. Good example is a in-memory database. Or in your case, maybe a simple in-memory implementation of your service.

Also, you should provide these test doubles as a separate library, where they will implement same interfaces/abstractions as your real library and can be easily subsituted either by DI container or simply just passing test instances instead of real instances.

If the above is how you would do it, then I would definitely recommend doing it. It is a great service to the user of your library to have a simple way to test their code works against your service without having to setup anything online or having a network connection when debugging their software. This of course depends that you put lots of care in making sure those test doubles behave as close as possible to real implementation.