2

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.

4
  • 2
    Angular does it for a few components, e.g. HttpClient and the Router have testing modules.
    – jonrsharpe
    Apr 2 '20 at 12:59
  • Who is consuming your API? Are they internal or external? I think that makes a big difference. There might be some benefits for internal consumers if everyone uses the same mocking framework, but I wouldn't bother with external consumers because they may never use it.
    – Dan Wilson
    Apr 2 '20 at 13:27
  • @jonrsharpe thanks for sharing the Angular precedent.
    – nelsonic
    Apr 2 '20 at 15:05
  • @DanWilson great question. all the libraries we create are open source so other people can use them. We then consume our own libraries in our Apps and in the case of the library in question, we are having to duplicate the mocks for our end-to-end tests which we don't like.
    – nelsonic
    Apr 2 '20 at 15:05
4
  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.

1
  • Great general guidance @RobertHarvey, thanks! We aren't using a specific mocking framework, just returning a mock response, but totally see your point. It would be lame to force a specific framework on others.
    – nelsonic
    Apr 2 '20 at 15:08
3

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.

1
  • a "TestDouble" is exactly what we had in mind when asking the question. Thanks for sharing a link to the appropriate terminology.
    – nelsonic
    Apr 2 '20 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.