pytest: ModuleNotFoundError when using the tests outside application code layout

im closing this issue as it relates to a miss-understanding of the python import system, the errors are indeed intended by python itself

from http://python-guide-pt-br.readthedocs.io/en/latest/writing/structure/

You can create a context.py file in tests:

from __future__ import absolute_import

import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

import mypkg

Then in your test file, add from .context import mypkg

@obestwalter has the correct solution. However, if you need something temporary while you are developing a package, you can simple add the following file to your tests directory, and then pytest will run it before the tests (so no changes are needed per-file when you make a final package, you just delete this one file):

conftest.py

import os
import sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

(This is one of the top google results for this error, so adding this even though the issue is closed)

PS: This is a hack, please use the editable install solution unless you have good reason to use this one. And do not forget to remove this before publishing to PyPI.

As a general recommendation: Always run tests against your installed package. If your package is not installable yet: make it installable. When you develop, install your package with pip install --editable <path/to/package>. When you need to release it somewhere: test the package with tox.

I am speaking from a place of major pain in the past, when I was not doing these things myself and when packaging was in a much worse state than it is today. That all went away now and is replaced by major packaging pains 😀

But joking aside: in most cases it is really much easier to create a simple setup.py to make your project installable and run tests against that, than going through all this hackery to make it work without.

Question 1: Following the Tests outside application code model (which is mentioned as “often a good idea”), this only runs for me if I add the __init__.py, otherwise pytest complains that the module being tested does not exist. Why is the __init__.py file mentioned as optional and only strictly necessary when test files do not have unique names, when it seems to be always necessary?

Question 2: What benefits does the pip install -e <path/to/package> method have over the the method from question 1?

@yfpeng @RonnyPfannschmidt i followed this exact same guide, but when i execute py.test-3 in test_pytest, i get following error:

Parent module '' not loaded, cannot perform relative import

I am reluctent to add an __init__.py in my tests directory since this is against what the documentation is offering. Pytest documentation does not provide IMO enough information on how to execute tests properly in that case either.

Do you know how to execute tests properly in that case?

@obestwalter thanks for the hint. In my case, i very much more appreciate having a code base i can consistently and continuously test (without any additional packaging pain). The scripts are made available through a pure git clone of a repo and IMO this use case should be supported “out of the box” for testing.

I have my project setup the exact same way, had the same issue but fixed it. My problem was having pytest installed system wide (outside of my virtual environment) and a package installed only in my virtualenv. pytest was looking in system site-packages. By installing pytest in virtualenv it solved the issue. Adding this comment in case you end up here from Google (like me).

Longer explanation: https://medium.com/@dirk.avery/pytest-modulenotfounderror-no-module-named-requests-a770e6926ac5

@RonnyPfannschmidt I fully agree; this is just useful if you aren’t ready to do an editable install or in special cases; and if so, this is a better solution than one non-editable example shown above because it converts much more easily to the correct solution.

In my case, I’m temporarily testing locally against CERN ROOT, and that has to be done against the system python on a Mac, and ROOT does not support pretty much anything nice in Python like virtual environments very well. This is a good way to temporarily test (once it’s in Travis, I can test against system Python there). My packages (from cookiecutter) is already installable from moment 0, I just don’t want to mess with my user directory by installing the system python one. So I’m sure there is at least one special case where this is useful. 😃

@henryiii i strongly suggest to avoid such hacks and use editable installs instead

@RonnyPfannschmidt I think there is a documentation issue here. I also followed the guide Good Integration Practices, and I would’ve felt pretty lost if I hadn’t stumbled upon this issue.

I think some sort of very short guide to how to use pip editable mode would be very welcome in said guide, if that is the recommended way to go no matter how you structure your tests, as long as it’s the “Tests outside application code” type 🙂

If you are using pipenv try pipenv install -e [OPTION] if you are developing you can try: pipenv install -e .'[dev]' after that you just need to run pytest -v and you are done

@GandalfSaxe you make a good point. We would appreciate a quick PR to the docs if you got the time, or create a new issue so it doesn’t get lost into this one. 👍

I think some sort of very short guide to how to use pip editable mode would be very welcome in said guide, if that is the recommended way to go no matter how you structure your tests […]

If you read a bit further down it is explained in the tox section: https://docs.pytest.org/en/latest/goodpractices.html#tox