On my Raspberry Pi model B, py.test and pytest are different
I am new to python and new to the Pi ...
So any clues welcomed
If I look at the command executed I have
For py.test:
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'pytest==2.7.2','console_scripts','py.test'
__requires__ = 'pytest==2.7.2'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('pytest==2.7.2', 'console_scripts', 'py.test')()
)
for pytest (run as python -m pytest ) :
#!/usr/bin/python -u
import warnings
warnings.simplefilter('default', DeprecationWarning)
from logilab.common.pytest import run
run()
Can someone explain why those 2 syntaxes ?
Could I use one or the other (and get the same results) ?
Many thanks
Both tools have nothing to do with each other. For some unfortunate reason logilab started shipping a binary called pytest in their logilab-common package, even thoug at that time the py.test testing tool already existed and it's package name already was pytest. And hence the confusion now.
But to clarify: py.test the testing tool from pytest.org installs a binary called py.test which is contained in the pytest python package and uses the pytest dstribution name on pypi.python.org.
Related
I have problem in importing pytest while writing a python code. "import pytest is grayed out.
Python is 3.8.3, Pycharm community edition.
pytest version 5.4.2, is successfully installed and can be seen in the project interpreter in pycharm. As well as I can see the installed path of pytest in python directory.
When running py.test command from console. It starts the test run shows "collected 0 items" and lastly ends with "NO TESTS RAN IN 0.05s"
If anyone running similar problems with some other packages kindly let me know.
TIA...
You simply run pytest from the commandline. There is no need to import pytest into a script. Take this Python script as an example:
def inc(x):
return x + 1
def test_answer():
assert inc(3) == 4
To run pytest on it, from the terminal (after changing to the right directory):
$ pytest
And you will then see the test outcome in the commandline as pytest automatically picks up the python scripts names test_*.py, where * is any name, e.g. test_increment.py. To have a test from your Python script run, name it with test_ as well to begin with.
Running pytest in the terminal is an option. In addition, Pycharm has integrated test suite for automatic discovery and collection of test tasks. You can use hotkey ctrl+shift+10 to run the test tasks directly in current file .
Problem
I'm using python 3.6.6 on Fedora 28. I have a project structure as follows :
test/__init__.py
test/signal.py
test/notsignal.py
If I run $ python3 -m doctest -v test/signal.py
I get:
10 items had no tests:
signal
signal.Handlers
signal.ItimerError
signal.Sigmasks
signal.Signals
signal._enum_to_int
signal._int_to_enum
signal.struct_siginfo
signal.struct_siginfo.__reduce__
signal.struct_siginfo.__repr__
0 tests in 10 items.
0 passed and 0 failed.
Test passed.
which, to me, clearly shows that doctest is trying to run on the built-in signal module. By renaming the file I was able to run docset. Am I missing something or is this a bug?
To reproduce
You may use the following shell script.
#!/bin/sh
mkdir -p test
touch test/__init__.py
echo -e ""'"'""'"'""'"'"\n>>> _ = print(f'Doctest at {__name__} was run.')\n"'"'""'"'""'"'"" > test/signal.py
cp test/signal.py test/notsignal.py
python3 -m doctest -v test/signal.py
python3 -m doctest -v test/notsignal.py
If you look at the doctest source, you can see that doctest tries to import the modules that you pass to it.
It's very likely that the standard library's signal module has already been imported:
$ python -c 'import sys;import doctest;print("signal" in sys.modules)'
True
When doctest tries the import the Python interpreter finds that there is already a module named "signal" in sys.modules and returns that rather than your signal module.
Perhaps this is a bug - maybe doctest could be smarter about how it imports - but in practice I think the best course of action is to rename your module. In general, having modules with the same names as standard library modules almost always causes problems.
I am using Pylint and Nose along with sniffer to lint and test my python application on every save. This is sniffer in case you are unaware https://pypi.python.org/pypi/sniffer
Here is the runnable responsible for running nosetests and pylint from scent.py file for sniffer
from sniffer.api import * # import the really small API
from pylint import lint
from subprocess import call
import os
import nose
#runnable
def zimmer_tests(*args):
command = "nosetests some_module/test --nologcapture --with-coverage --cover-config-file=zimmer_coverage_config"
lint.Run(['some_module/app'], exit=False)
return call(command, shell=True) == 0
Here, first lint.Run() runs pylint on my app. Then nosetest is executed on the app using call()
The Problem is that after I save the file nosetests run on updated version of the file however Pylint uses the same old version. I have to restart sniffer every time for pylint to get new version of files.
I assume this is not a problem of sniffer's configuration since nosetests is able to get the new version of file every time. Still I am not sure.
My pylintrc file is almost the same we get from generate command pylint --generate-rcfile > .pylintrc with some minor application specific tweaks.
As pointed by #KlausD. in comments, the lint.Run() was using files from cache as it was being called from a still running process. Calling pylint from command line worked as expected.
Here is the modified code
#runnable
def zimmer_tests(*args):
command_nose = "nosetests some_module/test --nologcapture --with-coverage --cover-config-file=zimmer_coverage_config"
command_lint = "pylint some_module"
call(command_lint, shell=True)
return call(command_nose, shell=True) == 0
I'm writing a separate nose2 tests.py for my program and because I want it to run on both Windows and Linux fairly seamlessly I've decided to forgo using the normal commandline nose2 and instead import it in the file and run it from there.
if __name__ == '__main__':
import nose2
nose2.main()
This works fine, no problems. But I'd like the verbose output and I can't see how to get it to do this. I've tried:
nose2.main("-v")
nose2.main(kwargs="-v")
nose2.main(args="-v")
Anyone know how to get the imported version of nose2 to run in verbose mode?
Since the PluggableTestProgram class accepts the same parameters of unittest.TestProgram, you can pass verbosity to the main function as such:
nose2.main(verbosity=2) # default is 1
See: Unittest.main documentation about verbosity
I am having some trouble trying to debug some unit tests through the pudb debugger.
The tests run fine with python, but I had no luck runnign them with pudb.
I isolated the problem, getting to the following sample code:
class Math:
def pow(self, x, y):
return x ** y
import unittest
class MathTest(unittest.TestCase):
def testPow23(self):
self.assertEquals(8, Math().pow(2, 3))
def testPow24(self):
self.assertEquals(16, Math().pow(2, 4))
if __name__ == '__main__':
unittest.main()
The tests run fine:
$ python amodule.py
.
----------------------------------------------------------------------
Ran 2 tests in 0.001s
OK
But if running through pudb, it gives me the output:
----------------------------------------------------------------------
Ran 0 tests in 0.000s
OK
I've tried running using pudb amodule.py and also with python -m pudb.run amodule.py, but it makes no difference -- no tests are run in one or another way.
Should I be doing something different to debug unit tests using pudb?
Try placing a breakpoint on a useful line in your code:
from pudb import set_trace; set_trace()
The ways you tried to launch it might interfere with test discovery and/or not run your script with a __name__ of '__main__'.
Since this is a popular question, I feel I should also mention that most test running tools will require you to pass in a switch to prevent it from capturing the standard output and input (usually it's -s).
So, remember to run pytest -s when using Pytest, or nosetests -s for Nose, python manage.py test -s for Django tests, or check the documentation for your test running tool.
You can set a breakpoint even easier by:
import pudb; pu.db