pylint complains on py.test: "Module 'pytest' has no 'raises' member" - python

With the following code:
import pytest
def test_a():
with pytest.raises(Exception):
1/0
If I run pylint on it, it will make a complain that "raises" is not a member of module pytest:
E: 3,9:test_a: Module 'pytest' has no 'raises' member
Which is obviously not true. Any idea why pylint is making such a mistake? Is this a known bug?
py.test version:
> py.test --version
This is py.test version 2.2.3, imported from C:\Python27\lib\site-packages\pytest.pyc
PyLint version:
> pylint --version
No config file found, using default configuration
pylint 0.25.1,
astng 0.23.1, common 0.57.1
Python 2.7.2 (default, Jun 24 2011, 12:22:14) [MSC v.1500 64 bit (AMD64)]

You can silence this in a pylintrc file with:
ignored-classes=pytest

Last time I looked pylib does some heavy dynamic in low level python stuff, such as completely redefining the import code. It is very likely that this completely baffles pylint/astng, and prevents it from getting what is inside the pytest module: pylint/astng does not import the code it analyzes, it parses it, meaning that stuff which is dynamically initialized at import time will usually go unnoticed, which in turn generates false positives such as the one you report.
From there, you face the following choices:
use another unittest framework, less dynamic than py.test
silence the warnings / errors on your test code manually
use another linter which is happier than pylint on py.test (I'm interested to know how pychecker / pyflakes fare on that code)
write the astng plugin which will help astng grok the pylib tricks and submit it as a patch to the astng maintainers (and get extra credit from that)

Related

How can I make mypy tell me I am using features that are unsupported in older Python versions?

As an example, executing this code with Python versions older than 3.9 will raise an exception:
from concurrent.futures import Future
f: Future[int]
TypeError: 'type' object is not subscriptable
But mypy will not complain (I'm using mypy 0.910):
Success: no issues found in 1 source file
Explicitly specifiying the Python version that mypy will use (e.g. --python-version=3.8) does not change this.
Numerous times I have fallen into the trap of writing code that uses features from newer Python versions, assuming that mypy will tell me if I made any errors, to then discover these errors only later at runtime.
How can I tell mypy to not assume features from certain Python versions (which I don't even have installed) to exist?
I'll take a guess: by running it with older mypy versions.
You could set up CI to run with every mypy version you require, and locally use virtual envs for each version
Mypy seems to already work as expected with built-in types, but fails in other cases, like Future above, or queue.Queue.
After reading Mypy docs – Annotation issues at runtime and Issue #7907 – Implement PEP 585 I'm not sure if this is a bug or intentional. Maybe the assumption is that the runtime errors can be avoided by using from __future__ import annotations.
After reading this answer it might be that this is a flaw in the Python standard library, or rather its typeshed, which promises more than is actually implemented, and mypy can't do anything about it.
Works:
# example1.py
x: list[int]
$ mypy --python-version=3.8 example1.py
example1.py:1: error: "list" is not subscriptable, use "typing.List" instead
$ mypy --python-version=3.9 example1.py
Success: no issues found in 1 source file
Works:
# example2.py
d: dict[str, int]
$ mypy --python-version=3.8 example2.py
example2.py:1: error: "dict" is not subscriptable, use "typing.Dict" instead
$ mypy --python-version=3.9 example2.py
Success: no issues found in 1 source file
Fails:
# example3.py
from queue import Queue
q: Queue[int]
$ mypy --python-version=3.8 example3.py
Success: no issues found in 1 source file
$ python3.8 example3.py
Traceback (most recent call last):
File "example3.py", line 2, in <module>
q: Queue[int]
TypeError: 'type' object is not subscriptable
Workaround:
# example4.py
from __future__ import annotations
from queue import Queue
q: Queue[int]
print('ok')
$ mypy --python-version=3.8 example4.py
Success: no issues found in 1 source file
$ python3.8 example4.py
ok

Is Python 3.9.6 compatible with pytest 6.2.5?

I am trying to test views and models for Django REST API written in pycharm and have installed pytest for this. I have written some tests and when I wanted to start them I got the following error message:
ERROR: usage: _jb_pytest_runner.py [options] [file_or_dir] [file_or_dir] [...]
_jb_pytest_runner.py: error: unrecognized arguments: --cov=frontend --cov-report=html
I have then checked if I have installed pytest properly and it seems I have. I have both Python 2.7.16 as well as Python 3.9.6 installed but am using Python 3. Could this be a compatibility problem or is it something else?
I have tried starting the tests both through the terminal using py.test and just in the IDE itself. I keep getting this same error message.
I have tried the approach below:
py.test: error: unrecognized arguments: --cov=ner_brands --cov-report=term-missing --cov-config
yet I seem to get the same error.
ERROR: usage: _jb_pytest_runner.py [options] [file_or_dir] [file_or_dir] [...]
_jb_pytest_runner.py: error: unrecognized arguments: --cov=frontend --cov-report=html
Does anyone know how I could solve this issue?
Thanks in advance.
First of all, yes, Python 3.9.6 is compatible with pytest 6.2.5, however, you appear to be missing a few dependencies. pytest is one of many different Python packages, and you appear to have installed that successfully, so you're halfway there.
There are a few different coverage plugins that work with pytest, and those need to be installed separately. Here are the two most common coverage plugins for Python and pytest:
https://pypi.org/project/coverage/
https://pypi.org/project/pytest-cov/
The first one, coverage is installed with:
pip install coverage
The second one, pytest-cov is installed with:
pip install pytest-cov
Based on your run command, you appear to want to use pytest-cov. After you've installed that, you can verify that pytest has those new options by calling pytest --help:
> pytest --help
...
coverage reporting with distributed testing support:
--cov=[SOURCE] Path or package name to measure during execution (multi-allowed). Use --cov= to
not do any source filtering and record everything.
--cov-reset Reset cov sources accumulated in options so far.
--cov-report=TYPE Type of report to generate: term, term-missing, annotate, html, xml (multi-
allowed). term, term-missing may be followed by ":skip-covered". annotate, html
and xml may be followed by ":DEST" where DEST specifies the output location.
Use --cov-report= to not generate any output.
--cov-config=PATH Config file for coverage. Default: .coveragerc
--no-cov-on-fail Do not report coverage if test run fails. Default: False
--no-cov Disable coverage report completely (useful for debuggers). Default: False
--cov-fail-under=MIN Fail if the total coverage is less than MIN.
...
Alternatively, you might be able to get the same results you're looking for using coverage:
coverage run -m pytest
coverage html
coverage report
And that will also give you a coverage report even if not using pytest-cov options.

VSCode pytest test discovery fails

Pytest test discovery is failing. The UI states:
Test discovery error, please check the configuration settings for the tests
The output window states:
Test Discovery failed:
Error: Traceback (most recent call last):
File "C:\Users\mikep\.vscode\extensions\ms-python.python-2019.4.11987\pythonFiles\testing_tools\run_adapter.py", line 16, in <module>
main(tool, cmd, subargs, toolargs)
File "C:\Users\mikep\.vscode\extensions\ms-python.python-2019.4.11987\pythonFiles\testing_tools\adapter\__main__.py", line 90, in main
parents, result = run(toolargs, **subargs)
File "C:\Users\mikep\.vscode\extensions\ms-python.python-2019.4.11987\pythonFiles\testing_tools\adapter\pytest.py", line 43, in discover
raise Exception('pytest discovery failed (exit code {})'.format(ec))
Exception: pytest discovery failed (exit code 3)
Here are my settings:
{
"python.pythonPath": ".venv\\Scripts\\python.exe",
"python.testing.pyTestArgs": [
"tests"
],
"python.testing.unittestEnabled": false,
"python.testing.nosetestsEnabled": false,
"python.testing.pyTestEnabled": true
}
I can run pytest from the command line successfully FWIW.
I spent ages trying to decipher this unhelpful error after creating a test that had import errors. Verify that your test suite can actually be executed before doing any deeper troubleshooting.
pytest --collect-only is your friend.
This is not a complete answer as I do not know why this is happening and may not relate to your problem, depending how you have your tests structured.
I resolved this issue by putting an __init__.py file in my tests folder
E.G.:
├───.vscode
│ settings.json
│
├───app
│ myapp.py
│
└───tests
test_myapp.py
__init__.py
this was working a few days ago without this but the python extension was recently updated. I am not sure if this is the intended behavior or a side effect of how discoveries are now being made
https://github.com/Microsoft/vscode-python/blob/master/CHANGELOG.md
Use Python code for discovery of tests when using pytest. (#4795)
I just thought I would add my answer here as this might well affect someone who uses a .env file for their project's environment settings since it is such a common configuration for 12 factor apps.
My example assumes that you're using pipenv for your virtual environment management and that you have a .env file at the project's root directory.
My vscode workspace settings json file looks like below. The crucial line for me here was "python.envFile": "${workspaceFolder}/.env",
{
"python.pythonPath": ".venv/bin/python",
"python.linting.enabled": true,
"python.linting.pylintEnabled": true,
"python.linting.pycodestyleEnabled": false,
"python.linting.flake8Enabled": false,
"python.linting.pylintPath": ".venv/bin/pylint",
"python.linting.pylintArgs": [
"--load-plugins=pylint_django",
],
"python.formatting.provider": "black",
"python.formatting.blackArgs": [
"--line-length",
"100"
],
"python.testing.unittestEnabled": false,
"python.testing.nosetestsEnabled": false,
"python.testing.pytestEnabled": true,
"python.testing.pytestPath": ".venv/bin/pytest",
"python.envFile": "${workspaceFolder}/.env",
"python.testing.pytestArgs": [
"--no-cov"
],
}
I hope this saves someone the time I spent figuring this out.
In my case the problem with vscode being unable to discover tests was the coverage module being enabled in the setup.cfg (alternatively this could be a pytest.ini), i.e.
addopts= --cov <path> -ra
which caused the test discovery to fail due to low coverage. The solution was to remove that line from the config file.
Also, as suggested in the documentation:
You can also configure testing manually by setting one and only one of the following settings to true: python.testing.unittestEnabled, python.testing.pytestEnabled, and python.testing.nosetestsEnabled.
In settings.json you can also disable coverage using --no-cov flag:
"python.testing.pytestArgs": ["--no-cov"],
EDIT:
Slightly related - in case of more complex projects it might be also necessary to change the rootdir parameter (inside your settings.json) when running tests with pytest (in case of ModuleNotFoundError):
"python.testing.pytestArgs": [
"--rootdir","${workspaceFolder}/<path-to-directory-with-tests>"
],
Seems like a bug in the latest version of VS Code Python extension. I had the same issue, then I downgraded the Python extension to 2019.3.6558 and then it works again. So we should go to our VS Code extensions list, select the Python extension and "Install another version..." from the setting of that extension.
I hope this works for you too.
I resolved the issue by upgrading pytest to the latest version: 4.4.1 with "pip install --upgrade pytest". I was apparently running an old version 3.4.2
Before begin the tests discovery, check that python.testing.cwd points correctly to your tests dir and your python.testing.pytestEnabled is set to true.
Once those requirements are set correctly, run tests discovery and its output (see OUTPUT window). You should see something like this:
python $HOME/.vscode/extensions/ms-python.python-$VERSION/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir $ROOT_DIR_OF_YOUR_PROJECT -s --cache-clear
Test Discovery failed:
Error: ============================= test session starts ==============================
<SETTINGS RELATED TO YOUR MACHINE, PYTHON VERSION, PYTEST VERSION,...>
collected N items / M errors
...
It's important to highlight here the last line: collected N items / M errors. The following lines will contain info about the tests discovered by pytest. So your tests are discoverable but there are errors related to their correct execution.
The following lines will contain the errors which in most of the cases will be related to an incorrect import.
Check that all your dependencies have been downloaded previously. If you are working with specific versions of dependencies (on therequirements.txt file you have something like your_package == X.Y.Z) be sure that it's the right version that you need to.
If you are having trouble with pytest I was struggling with the discovery test part.
Reading some open issue (other) in vscode I found a workaround using the test-adapter extension
market_place_link
The extention works like a charm. (and solve my discovery problem)
In my case, it was the vscode python extension problem.
I switched the test platform from pytest and switched to it back again, and the tests got discovered.
It seems that when testing is universally enabled for all python projects and it fails to discover tests at the beginning, it fails forever!
Test files need to be named test_*.py or *_test.py for pytest collection to work.
Then run pytest --collect-only at the command line to make sure all of the tests are found. Then magically, the flask icon in VSCode suddenly shows the test files and their tests.
As a noob, I was putting my unit tests inside the module files, since I was following the pattern of unittest, and then running pytest *.py. That doesn't work with pytest, and I didn't find a command line argument override the naming convention.
I searched in the settings for "python" and found this:
Switching to pytest automatically detect my tests:
This error is so frustrating..
In my case the error fixed by modifying the python.pythonPath parameter in settings.json (found inside .vscode folder under project root directory), to the path which I obtained using which python in terminal (e.g. /usr/local/var/pyenv/shims/python)
I use pyenv with python3.9, and my error said previously:
Error: Process returned an error: /Users/"user-name"/.pyenv/shims/python:
line 21: /usr/local/Cellar/pyenv/1.2.23/libexec/pyenv: No such file or
directory
at ChildProcess.
(/Users/"user-name"/.vscode/extensions/littlefoxteam.vscode-python-test-adapter-0.6.8/out/src/processRunner.js:35:36)
at Object.onceWrapper (events.js:422:26) at ChildProcess.emit
(events.js:315:20) at maybeClose (internal/child_process.js:1021:16)
at Process.ChildProcess._handle.onexit
(internal/child_process.js:286:5)
In my case, I had to make sure that I was using the right interpreter where the libraries where installed (I used a virtual environment) but the interpreter was pointing to the globally installed python. After changing the interpreter to that of the virtual environment, it worked.
Looking at https://docs.pytest.org/en/latest/usage.html#possible-exit-codes it seems pytest itself is falling over do to some internal error.
I had this same issue and tracked it down to my pytest.ini file. Removing most of the addopts from that file fixed the issue.
I had this problem and struggle with it for hours. I think that there is a special resolution for every other platform configuration. My platform is:
VSCode: 1.55.0 (Ubuntu)
Pytest: 6.2.3
MS Python extension (ms-python.python 2021.3.680753044)
Python Test Explorer for Visual Studio Code (littlefoxteam.vscode-python-test-adapter - 0.6.7)
The worst thing has that the tool itself does not have a standard output (at least that I know of or could find easily on the internet).
In the end, the problem was
--no-cov
parameters that was not recognized by the VSCode testing explorer tool (that I copied from some page on the internet) and the error was showed by the extension littlefoxteam.vscode-python-test-adapter and it may help you to find where things are broken.
In my case, same problem appeared each time when flake8 linter reported errors. Even one error was enough to fail VS Code test discovery.
So the fix is either disable the linter or fix linter errors.
I use setup described here.
2021-12-22
Please find below the settings I used to get pytest working in VsCode after much frustration. I found many helpful pieces of advice here and elsewhere on the internet, but none were complete enough to spare me a bit of cursing. I hope the following will help someone out. This setup allows me to run testing visually from the test explorer extension and also from the integrated terminal. I am using a src format in my workspace and Conda for environment management. The settings related to the terminal setup keep me from having to manually enable my Conda environment or set the python path. Possibly people who have been using VSCODE for more than two days could add something nice to make this better and/or more complete.
##### Vscode info:
Version: 1.63.2 (Universal)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:37:28.172Z (1 wk ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0
##### Testing Extension:
Python Test Explorer for Visual Studio Code
extension installed, v. 0.7.0
##### Pytest version
pytest 6.2.5
##### Directory Structure:
workspace
.env
./src
__init__.py
code1.py
code2.py
./tests
__init__.py
test_code1.py
test_code2.py
##### .env file (in root, but see the "python.envFile" setting in settings.json)
PYTHONPATH=src
#####. settings.json
{
"workbench.colorTheme": "Visual Studio Dark",
"editor.fontFamily": " monospace, Menlo, Monaco, Courier New",
"python.testing.unittestEnabled": false,
"python.testing.cwd": ".",
"terminal.integrated.inheritEnv": true,
"python.envFile": "${workspaceFolder}/.env",
"python.defaultInterpreterPath":
"~/anaconda3/envs/mycurrentenv/bin/python",
"pythonTestExplorer.testFramework": "pytest",
"python.testing.pytestEnabled": true,
"python.testing.pytestArgs": [
"tests"
],
"python.terminal.activateEnvironment": true,
"python.terminal.activateEnvInCurrentTerminal": true,
"terminal.integrated.env.osx": {
"PYTHONPATH": "${workspaceFolder}/src:${env:PYTHONPATH}"
}
}
Here is generic way to get Django tests to run with full vscode support
Configure python tests
Choose unittest
Root Directory
test*.py
Then each test case will need to look like the following:
from django.test import TestCase
class views(TestCase):
#classmethod
def setUpClass(cls):
import django
django.setup()
def test_something(self,):
from user.model import something
...
Any functions you want to import have to be imported inside the test case (like shown). The setUpClass runs before the test class is setup and will setup your django project. Once it's setup you can import functions inside the test methods. If you try to import models/views at the top of your script, it will raise an exception since django isn't setup. If you have any other preinitialization that needs to run for your django project to work, run it inside setUpClass. Pytest might work the same way, I haven't tested it.
There are several causes for this.
The simple answer is, it is not perfect. Furthermore, Python is not native to VS Code; Python extensions may not be playing nice either.
I have observed some mitigating measures, though.
NB VS Code didn't "design" test discovery; that is the job of the testing framework. Make sure you have a basic grasp on how it works.
Troubleshooting
For every "battery" of tests, VS Code will gladly tell you what went wrong, right in the Test view panel. To see this, expand the bar with the name of the project, and hover your mouse over the line that is revealed. Look at the traceback.
In the image above, the error is "No module named src". This is more interesting than it sounds. If I import a file from another file, that import path may not be visible to the test discovery mechanism. It may be running from a different "cwd". The best you can do is try to figure out the topmost path of your project, and either add or remove path qualifiers. Until it works.
Main causes
From time to time, VS Code will lose info on the project test configuration. Use command window (Ctrl + Shift + P) to either:
(re)scan tests
(re)configure test spec for the project <-- important!
restart Python Language Server
Python is supposed to remove the need for the empty __init__.py; it seems VS Code loves those. They should be in each folder that leads to a test folder. Not every folder, but the top-down path.
Depending on what you select as the "root test folder" in the test configuration, it might have different meaning based on what VS Code thinks is the root of your project. That probably goes for any specific folder too.
import. VS Code doesn't like syntax errors. It is possible some syntax errors will not get highlighted in the code.
This (unfortunately) goes for all the imports in your file. But you shouldn't test invalid code anyway, right?
Minor buggy behaviors
Running some other visible test might help refresh the discovery process.
VS Code should automatically (by setting) refresh tests on each Save operation. But it doesn't hurt to refresh it manually.
TLDR
Look at the error items in the test panel
Re-configure project test discovery parameters from time to time
Make sure you don't have syntax errors (visible or not)
Create empty __init__.pys in each folder of your project that leads to the test folder
Clean up your import logic
P.S. The Test view has been extensively worked on and improved much over the course of 1 year. Expect changes in behavior.

pylint 1.6.3 reports E1101(no-member) for xml

We are using the ElementTree library in our project. This comes from the standard library, but for some reason pylint chokes on it. It always reports an E1101 on any reference on an ElementTree object. Here is a sample bit of code to demonstrate this:
import xml.etree.ElementTree as ET
test = ET.parse('test.xml')
config = test.find('.//configuration')
print(config)
for role in config.findall('.//role'):
print(role)
The output from pylint always throws an E1101:
$ pylint --rcfile=pylint.cfg -E test.py
************* Module orion-scripts.test
E: 7,12: Instance of 'int' has no 'findall' member (no-member)
But the program runs just fine:
$ python test.py
<Element 'role' at 0x1052dfe50>
<Element 'configuration' at 0x1052dfe10>
I found a number of solutions to similar problems, but so far none have worked for this one. I've tried:
Setting an ignored class with ignored-classes=xml.etree.ElementTree
Setting it as a generated member with generated-members=ET
Allowing any extension to run with unsafe-load-any-extension=yes
Nothing has worked and I'm currently just ignoring E1101 messages. However, this is a really bad option and I would much prefer to just ignore this particular class. If it helps, this is the version info for pylint:
$ pylint --version
No config file found, using default configuration
pylint 1.6.3,
astroid 1.4.7
Python 2.7.11 (default, Jan 22 2016, 08:28:37)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]

py.test: ImportError - cannot import ----

I am using someone else's code, available on GitHub. To run their code I created a virtualenv and installed all the dependencies listed - both python libraries and clones of other repositories. When I proceed to run the included tests, I get an ImportError:
Namespace(all=False, regr=False, sci=False, unit=True)
[localhost] local: py.test -x -v engine/test
==================================================================================== test session starts =====================================================================================
platform linux2 -- Python 2.7.6, pytest-2.8.2, py-1.4.31, pluggy-0.3.1 -- /home/compomics/local/METASPACE/SM_distributed/SM_engine/bin/python
cachedir: engine/test/.cache
rootdir: /home/compomics/local/METASPACE/SM_distributed/engine/test, inifile:
collecting 6 items / 1 errors
=========================================================================================== ERRORS ===========================================================================================
_______________________________________________________________________ ERROR collecting test_formula_img_validator.py _______________________________________________________________________
engine/test/test_formula_img_validator.py:7: in <module>
from engine.formula_img_validator import filter_sf_images,get_compute_img_measures, ImgMeasures
engine/formula_img_validator.py:7: in <module>
from pyIMS.image_measures import measure_of_chaos, isotope_image_correlation, isotope_pattern_match
E ImportError: cannot import name measure_of_chaos
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
================================================================================== 1 error in 0.99 seconds ===================================================================================
Fatal error: local() encountered an error (return code 2) while executing 'py.test -x -v engine/test'
However, if I open the python interpreter and try to do the exact same imports, it does it just fine without any error. Similar questions suggested:
adding an empty __init__.py to the test directory
making sure pytest is installed in the virtualenv
I did both these things, and the error persists.
I added to the beginning of the test script:
import os
print(os.environ["PYTHONPATH"].split(os.pathsep))
print(os.listdir("."))
and confirmed that the folder from where I'm trying to import is indeed in the resulting list.
Not sure how to proceed. Would appreciate any help I can get :)
In file formula_img_validator.py change
from pyIMS.image_measures import measure_of_chaos,isotope_image_correlation, isotope_pattern_match
to
from engine.pyIMS.image_measures import measure_of_chaos, isotope_image_correlation, isotope_pattern_match
That'll solve the problem. For complete solution go to GitHub for new updated code.
there was a conflict with other library
EDIT - this was my own stupidity for not remembering I had cloned a previous version of the dependent repos, which was also on my path, and that did not include the function this code was trying to load. Sorry for not having deleted the question when I noticed, I couldn't for the life of me find the delete button :)

Categories