Where to place stub classes that are used to mock by several test packages?

[WilliamDEdwards]

I have a package called A that provides a few classes. These classes perform external requests, so they are mocked in that package's unit tests. So far, so good.

Now, I have a few other packages that use the classes from package A. These packages are also unit tested, and also need to mock the classes from package A with the exact same stub classes that are used in the unit tests of package A itself.

As the stub classes are exactly the same for each and every package, it feels wrong to copy + paste them and end up with a lot of duplicate code. It would make more sense to ship these stub classes with package A (that provides the original classes) for use by all the packages that use the original classes from this package.

Example of that this causes a lot of duplicate code when added for each test module: https://bpa.st/CKHQ

However, I don't know where to place these stub classes. I can't find any guidelines on this or other packages that have done the same.

Someone on IRC said:

[16:46:21] [...] I have a library that is used by some external packages, and I would like to use the same mock classes for that library for all of those packages. It seems wrong to copy + paste those mock classes to all packages that use the library; it seems more logical to ship them with the library that provides the original classes. Is there a
[16:46:21] generally accepted convention on where I should place/how to export those mock classes?
[16:51:05] wedwards: mock classes as in fakes for testing?
[16:51:42] wedwards: I don't think this is done often, though I really wish it was. I'd expect them to be in a yourpackage.testsupport or somesuch

... but I'm not sure if this is the right answer.

[The-Compiler]

To add some more context to what I said in IRC: It's somewhat common for bigger projects to ship some kind of testing / test / test.utils / ... sub-package:

• Werkzeug/Flask
• Numpy
• Django

I don't see a reason why such a sub-package couldn't also contain mocks to use. Another approach (which I don't have an example of off-hand) is to ship a "fake backend" or "test backend" if some code already has multiple configurable backends to use for something.

Another approach you could take is to write a pytest plugin (say, pytest-A in your example) which is installable independently from A and provides the same functionality via pytest fixtures. If we're just talking about some mock classes, that seems like overkill to me though.

[WilliamDEdwards]

Thank you so much for your reply. You bring up three good ideas, so I will mark your reply as the answer.