We Keep Coding

ModuleNotFoundError when running unittest with subprocess

I'm writing tests in python's unittest and decided to use the module parameterized to deal with test parameterization. Now all's fine and dandy when I'm running tests directly with unittest's CLI - simply running python -m unittest in root directory launches all the tests as expected. However, I decided for my script to have it's own command flag to run the tests, so when you run, say, python ./main.py -t [additional arguments for unittest], the script itself runs python -m unittest [additional arguments for unittest]. For that to happen, I'm using subprocess.run. And this also works... well, to some extent. The problem is the following - when I'm using python -m unittest, no errors (except for the ones being tested) are raised, but using my script to run the tests raises ModuleNotFoundError: No module named 'parameterized', along with a few other dependencies my code is using. I'm clueless why is that happening.
To be honest I'm not that familiar with unittest, so maybe my approach is the problem, maybe I should handle this in completely different way. Any feedback would be much appreciated.

Python tox: show stdout/prints on successful test run?

Sometimes I want to print some statements, to make sure unittests are running fine (even if it passes), but can't find an option that enables it.
If tests fail, then it does show custom prints as output, but if it passes, it does ignore prints or logs (I mean, it dont see them on terminal output).
I tried using verbosity, like -vvvv, but it still ignores my prints. With nose there is an option like --nologcapture. Is there something similar in tox?

tox as such is just a generic venv creator, deps installer and command executor. It doesn't do output capturing (unless you use --parallel). So it is on a different abstraction level from nose. tox can run your tests or anything else that is runnable via command line.
Like you already mentioned for nose: depending on your test runner you might need to deactivate output capturing to see prints coming from the tests. So if you use pytest for example you can use pytest -s to disable all output capturing (also see docs)
You can also print something after you ran the test by adding something like this in your tox.ini testenv:
[testenv:test]
[...]
commands =
<some test command>
python -c 'print("All is fine."))'

pytest run only the changed file?

I'm fairly new to Python, trying to learn the toolsets.
I've figured out how to get py.test -f to watch my tests as I code. One thing I haven't been able to figure out is if there's a way to do a smarter watcher, that works like Ruby's Guard library.
Using guard + minitest the behavior I get is if I save a file like my_class.rb then my_class_test.rb is executed, and if I hit enter in the cli it runs all tests.
With pytest so far I haven't been able to figure out a way to only run the test file corresponding to the last touched file, thus avoiding the wait for the entire test suite to run until I've got the current file passing.
How would you pythonistas go about that?
Thanks!

One possibility is using pytest-testmon together with pytest-watch.
It uses coverage.py to track which test touches which lines of code, and as soon as you change a line of code, it re-runs all tests which execute that line in some way.

To add to #The Compiler's answer above, you can get pytest-testmon and pytest-watch to play together by using pytest-watch's --runner option:
ptw --runner "pytest --testmon"
Or simply:
ptw -- --testmon

There is also pytest-xdist which has a feature called:
--looponfail: run your tests repeatedly in a subprocess. After each run py.test waits until a file in your project changes and then re-runs the previously failing tests. This is repeated until all tests pass after which again a full run is performed.

The fastest setup I got was when I combines #lmiguelvargasf #BenR and #TheCompiler answer into this
ptw --runner "pytest --picked --testmon"
you first gotta have them installed by
pip3 install pytest-picked pytest-testmon pytest-watch

If you are using git as version control, you could consider using pytest-picked. This is a plugin that according to the docs:
Run the tests related to the unstaged files or the current branch
Demo
Basic features
Run only tests from modified test files
Run tests from modified test files first, followed by all unmodified tests
Usage
pytest --picked

setting breakpoints with nosetests --pdb option

nosetests --pdb let's me halt upon error or failure, but this is too late for my needs. Stepping through code during execution helps me debug where the problem is.
However, nosetests are helpful as they allow tests that rely on relative imports (i.e. tests in a package).
How can I set breakpoints before the tests are executed?
Currently I'm using:
python -m pdb /path/to/my/nosetests testfile.py
This solution isn't adequate. Nosetests interfere with pdb output, and my keyboard controls (e.g. arrow keys) are broken.
Using import pdb; pdb.set_trace() would seem like a good idea, however nosetests is blocking my access to the pdb console.

Even better than remembering to use -s is to use the set_trace variant that comes with Nose. Add
from nose.tools import set_trace; set_trace()
wherever you'd like to break in to the debugger. The stdin/out redirection will be taken care of for you. The only strange side effect I've run into is the inability to restart your code from within pdb (using run) while debugging during a nose run.

You can add
import pdb; pdb.set_trace()
anywhere in your source that you want to stop in the debugger.
Make sure you pass -s to nose so that it does not capture stdout.

If you have ipython, for unlimited awesomeness use:
import ipdb; ipdb.set_trace()
*unlimited awesomeness: just like ipython - auto-completion, coloring etc.

If you are using pytest, you can use
import pytest; pytest.set_trace()
See documentation.

How to use `pytest` from Python?

I'm working in a project that recently switched to the pytest unittest framework. I was used to calling my tests from Eclipse, so that I can use the debugger (e.g. placing breakpoints to analyze how a test failure develops). Now this is no longer possible, since the only way to run the tests is via the command line blackbox.
Is there some way to use pytest from within Python, so that one is not forced to drop out of the IDE? The tests should of course not be run in a separate process.

I think I can now answer my own question, it's pretty simple:
import pytest
pytest.main(args)
which is documented in the Section "Calling pytest from Python code".
Then I can run this module and/or start it with the integrated debugger.
args is the list of command-line arguments, so for example to run only particular tests I can use something like:
args_str = "-k test_myfavorite"
args = args_str.split(" ")
pytest.main(args)

It seems that now (py.test version 2.0+) someone can also do this :
import pytest
pytest.main('-x {0}'.format(argument))
# Or
# pytest.main(['-x', 'argument'])
Ref

This is now supported by pytest and described nicely in the documentation.
You can invoke pytest from Python code directly:
import pytest
pytest.main()
this acts as if you would call “pytest” from the command line. It will not raise SystemExit but return the exitcode instead. You can pass in options and arguments:
pytest.main(["-x", "mytestdir"])

For me it was this:
pytest.main(["-x", "path to test file", "args"])
For example:
import pytest
pytest.main(["-x", "/api/test", "-vv"])

Maybe you could give a try to pycharm it has direct integration with py.test (I use it at work) and debugger runs perfectly.

I have not tried with eclipse, but as was suggested in a related question, it is possible to use the --pdb command line option with py.test. Maybe it is possible to configure eclipse that way.
However, calling the standard import pdb;pdb.set_trace() will not directly call the debugger. First it will issue an error which in turn will activate the debugger. This might or might not make things work differently.

You can just run py.test --pdb if you just want to a debugger and don't need the IDE