I am fairly new to py.test and have tried to set up a couple of simple black box tests for some legacy code. The directory structure looks somewhat like this:
X:\
conftest.py
prgm_A\
src\
test\
test_A.py
prgm_B\
src\
test\
test_B.py
When I run py.test from X:\, using py.test v. 2.6.3 in Windows 7 (or XP), py.test returns the following type of error message:
___________ ERROR collecting /prgm_A/test/test_A.py __________________
import file mismatch:
imported module 'test_A' has this __file__ attribute:
X:\prgm_A\test\test_A.py
which is not the same as the test file we want to collect:
X:\\prgm_A\test\test_A.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for
your test file modules
<and the same for B>
I have removed the __pycache__ and .pyc files, but that did not work. That extra backslash after the drive letter looks really fishy, but I am quite sure I am not to blame for that.
When I try to run the same tests in linux (despite the fact that the programs are compiled for windows), py.test v. 2.5.1 does not have the same problem.
My workaround until now has been to run the tests for each individual program from its own test directory, but after our computers were migrated to Windows 7, this stopped working.
Any ideas?
Additional Facts/Observations
I forgot to say that the tests used to work under XP, with an earlier py.test?, provided that I stepped down to X:\prgm_[AB]\test and ran py.test from there.
Superstition: Inserting one extra level in the file structure, moving everything from X:\ to X:\one_extra_level, didn't make one bit of a difference.
I have managed to reproduce the problem with this minimal example:
# conftest.py:
import pytest
def returns_xyz():
return "xyz"
#pytest.fixture(scope="session")
def provider():
"""Provides a subprogram which returns the string 'xyz'."""
return returns_xyz
# prgm_[AB]\test\test_[AB].py:
import pytest
def test_xyz(provider):
assert "xyz" == provider()
Everything you need for resolving this issue is to remove the python path file. It's a file with this extension .pyc and remove also the folder __pycache__ if it's available on your test or project.
Lamine
As explained here, you just have to add an __init__.py file in your test folder and it will do the trick.
the issue moved to https://github.com/pytest-dev/pytest/issues/702
this is not a bug, as far as i can tell the python module name is the same for both test modules
py.test complains about different files ending up with the same module name, thus breaking details
can you verify?
edit
its been verified as bug
Delete all .pyc file in your project directory
Execute Command : find . -name *.pyc -delete
It worked for me!
Related
I am working creating some testing infrastructure and struggling with taking care of all the dependencies correctly.
The directory structure I have looks like:
conftest.py
kernels/
|-kernel_1/
|---<kernel_src1>
|---__init__.py
|---options.json
|---test/
|-----test_func1.py
|-kernel_2/
|---<kernel_src2>
|---__init__.py
|---pytest.ini
|---options.json
|---scripts/
|-----__init__.py
|-----some_module.py
|---test/
|-----test_func2.py
When I call pytest on any of these tests, the test first compiles and simulates the kernel source code (C++) and compares the output against golden that is generated in python. Since all the kernels will be compiled individually, I create an output directory to store compile/simulation logs along with some header files that we generated in the kernel_1 directory.
For example, pytest kernel_1/test/test_func1.py will create a directory in kernel_1/build_test_func1/<compile/sim logs>.
I use the conftest.py which updates cwd to the test directory based on the accepted answer here:
Change pytest working directory to test case directory
I also added pytest.ini to add kernel_2 to the pythonpath when running test_func2 so we can find modules in scripts folder:
[pytest]
pythonpath=.
Tests run correctly when calling it from:
cd kernel_2/; pytest
cd kernel_2/test; pytest
cd kernel_2; pytest test/test_func1.py
cd kernel_2/test; pytest test_func1.py
The test also runs correctly when calling it like this: pytest kernel_2/test/test_func2.py
But I start seeing ModuleImportError when calling it from top-level without specifying the test
pytest
ImportError while importing test module '<FULL_PATH>/kernel_2/test/test_func2.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
<FULL_PATH>miniconda3/envs/pytest/lib/python3.7/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
kernel_2/test/test_func2.py:8: in <module>
from scripts.some_module import some_func
E ModuleNotFoundError: No module named 'scripts'
The issue looks when collecting pytest.ini in a specific kernel doesn't take effect when calling pytest, but I haven't been able to find a way to fix this issue. Any comments, concerns are appreciated!
Say I develop a package with a limited set of dependencies (for example, LinearAlgebra).
In the Unit testing part, I might need additional dependencies (for instance, CSV to load a file). I can configure that in the Project.toml all good.
Now from there and in VS Code, how can I debug the Unit tests? I tried running the "runtests.jl" in the debugger; however, it unsurprisingly complains that the CSV package is unavailable.
I could add the CSV package (as a temporary solution), but I would prefer that the debugger run with the configuration for the unit testing; how can I achieve that?
As requested, here is how it can be reproduced (it is not quite minimal, but instead I used a commonly used package as it give confidence the package is not the problem). We will use DataFrames and try to execute the debugger for its unit tests.
Make a local version of DataFrames for the purpose of developing a feature in it. I execute dev DataFrames in a new REPL.
Select the correct environment (in .julia/dev/DataFrames) through the VS-code user interface.
Execute the "proper" unit testing by executing test DataFrames at the pkg prompt. Everything should go smoothly.
Try to execute the tests directly (open the runtests.jl and use the "Run" button in vs-code). I see some errors of the type:
LoadError: ArgumentError: Package CategoricalArrays not found in current path:
- Run `import Pkg; Pkg.add("CategoricalArrays")` to install the CategoricalArrays package.
which is consistent with CategoricalArrays being present in the [extras] section of the Project.toml but not present in the [deps].
Finally, instead of the "Run" command, execute the "Run and Debug". I encounter similar errors here is the first one:
Test Summary: | Pass Total
merge | 19 19
PASSED: index.jl
FAILED: dataframe.jl
LoadError: ArgumentError: Package DataStructures not found in current path:
- Run `import Pkg; Pkg.add("DataStructures")` to install the DataStructures package.
So I can't debug the code after the part requiring the extras packages.
After all that I delete this package with the command free DataFrames at the pkg prompt.
I see the same behavior in my package.
I'm not certain I understand your question, but I think you might be looking for the TestEnv package. It allows you to activate a temporary environment containing the [extras] dependencies. The discourse announcement contains a good description of the use cases.
Your runtest.jl file should contain all necessary imports to run tests.
Hence you are expected to have in your runtests.jl file lines such as:
using YourPackageName
using CSV
# the lines with tests now go here.
This is a standard in Julia package layout. For an example have a look at any mature Julia such as DataFrames.jl (https://github.com/JuliaData/DataFrames.jl/blob/main/test/runtests.jl).
My developer friend who has the luxury of developing in a non-Windows environment has been raving about Compass. I finally decided I wanted to give it a try. I'm tired of trying to keep up with all of the intricacies of cross-browser CSS.
So, I found it on NuGet, and installed it.
I installs to my solutions root directory in the packages directory:
$(SolutionDir)packages\Ruby.Compass.0.12.2.3\
It comes with a Readme that states the following message:
Ruby Compass v. 0.12.2
Compass is installed in its own NuGet package dir, and available by
'compass' command in "packages\Ruby.Compass.0.12.2.3" folder.
To compile Compass files during build, add the next line to the
project pre-build events:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile
"$(ProjectDir)."
So, I placed the line in my pre-build events, saved, and tried to build my project. However, I get an error as follows:
The command
""$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)."" exited with code 1.
Notice: It actually shows the full path to the ProjectDir and SolutionDir as it's supposed too in the error message. I replaced them with the tokens to keep the project name unanimous.
Let me mention that I tried variations of the suggestion pre-build line:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css\test.scss"
The first one just removed that trailing .. The second one pointed it to the directory where all my css files are stored. The third one pointed it to the exact file I was trying to compile was located.
I opened up compass.cmd which is the file it is calling, and it looks like the following:
#echo off
"%~dp0ruby\bin\compass" %*
I'm assuming this calls the compass file in the ruby/bin folder, which looks like this:
#!C:/downloads/ruby-2.0.0-p247-x64-mingw32/ruby-2.0.0-p247-x64-mingw32/bin/ruby.exe
#
# This file was generated by RubyGems.
#
# The application 'compass' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
if ARGV.first
str = ARGV.first
str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
if str =~ /\A_(.*)_\z/
version = $1
ARGV.shift
end
end
gem 'compass', version
load Gem.bin_path('compass', 'compass', version)
From there, I'm not sure what is going on. I'm not a Ruby person.
Is there an issue that I'm overlooking here?
Has anyone else been able to install Ruby.Compass via NuGet?
How can I get this working in Visual Studio without having to fight with Ruby?
From: http://codewith.us/automating-css-generation-in-visual-studio-using-sasscompass/
"Note that, if there are issues with your SCSS files, you will receive some variation of the error below.
Error 36 The command "del "C:Projectspubliccss*.css" /S
compass compile "C:Projectspublic" --force" exited with code 1.
Open your Output window (click View -> Output or press Ctrl+W, O), and select “Build” in the “Show output from:” menu. Scroll up until you find your command in the log and you should get a little more insight into what portion of the command failed."
I have a mixed Python/C++ library with test files mixed in amongst source files in the same directories. The layout looks like
/home/irving/geode
geode
__init__.py
vector
__init__.py
test_vector.py
...
...
Unfortunately, the library is unusable in-place since it lacks .so extension modules. Question: Can I make py.test always use an installed version, even when run from /home/irving/geode or a subdirectory?
The test files have from __future__ import absolute_import, and run fine if executed directly as scripts. For example, if I do
cd geode/vector
./test_vector.py
which does import geode, it finds the installed version. However, if I run py.test in geode/vector, it finds the local copy of geode, and then dies.
I think you have two options:
run py.test --pyargs geode.vector.test_vector to make pytest interpretet the argument as an import path, deriving the file system path from it. This should run the test against the installed version.
move the tests out into a tests directory without an __init__.py file. This way you need to pip install -e . to work in-place or can do python setup.py install and the py.test tests to run tests against the installed version.
I have different behaviour of compiler, when building project from IDE and from command-line, which I can not explain.
The detailed issue's description is rather big, but it's really simple.
I have a C++ Builder project, which has a PAS-file included (IncludeUnits.pas). This pas-file has several units and inc-files listed. These files are located in separate folders and these folders are listed in library&include paths in project's options.
Folders layout:
C:\Demo\Bin
C:\Demo\Project
C:\Demo\Project\CBuilder5
C:\Demo\Project\Common
C:\Demo\Source
C:\Demo\Source\Common
Bin is output folder, Project/CBuilder5 holds project (bpr-file), Project/Common holds included pas-file (IncludeUnits.pas), Source and Source/Common hold other files (pas&inc). I think that it's pretty usual layout.
C:\Demo\Project\Common\ IncludeUnits.pas :
unit IncludeUnits;
interface
uses
Test;
implementation
end.
C:\Demo\Source\ Test.pas :
unit Test;
interface
{$I Test.inc}
implementation
end.
C:\Demo\Source\Common\ Test.inc :
// this file is empty
If I compile this project from C++ Builder IDE - it will compile fine. C++ Builder IDE doesn't have any additional paths in IDE settings set.
Now, I want to compile it from command-line. First, I issue
bpr2mak.exe MyProject.bpr
command.
This command creates MyProject.mak file, where I can see all paths ("....\Source" and "....\Source\Common" are the paths in question):
...
INCLUDEPATH = $(BCB)\include;$(BCB)\include\vcl;..\Common;..\..\Source;..\..\Source\Common
LIBPATH = $(BCB)\lib\obj;$(BCB)\lib;..\Common;..\..\Source;..\..\Source\Common
...
Now, I run make command:
make.exe -B -f"MyProject.mak"
It gives me the following output:
C:\PROGRA~1\Borland\CBUILD~2\BIN\dcc32 -N2....\Bin -N0....\Bin -$Y+ -$W -$R -v -JPHNE -M -UC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common -D_DEBUG;_RTLDLL;NO_STRICT -OC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common --BCB ..\Common\IncludeUnits.PAS
Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(6) C:\Demo\Source\Test.pas(1) C:\Demo\Source\Test.pas(5) Fatal: File not found: 'Test.inc'
As you can see - all search path is passed to compiler and the file (Test.inc) is all here - in that Source\Common folder. But still compiler can't find it?
Of course, I run both commands from folder with bpr-file. And changing paths to absolute doesn't help.
Copying Test.inc from Source\Common to Source will help. Changing {$I Test.inc} to {$I Common\Test.inc} will also help.
Why? It seems that I'm missing something. Remember: project have no problems with compiling from IDE, Test.inc is found without copying or changing declaration. Did I miss some switch to make or dcc32?
I found the reason: command line for dcc32 misses -I switch, which specifies paths for include files.
For some reason, bpr2mak doesn't respect this option. Fortunately, it allows you to specify alternate template for conversion bpr -> mak. I edited default template and added "-I" option to it, pass new template to bpr2mak - and it worked.