I have some parametrized tests that use a fixture defined in conftest. My tests are failing when pytest-xdist is used but pass with standard pytest. The fixture creates a directory which is then used by the test and I'm getting IOErrors.
From the output, it looks like the two failing parametrized tests are either being collected and/or being run multiple times. Note in the output below that test_save_load[obj2] and test_save_load[obj0] are failing and these appear twice so I assume they are being run multiple times. I can write the test differently to not parametrize; but was curious to understand this problem. Any ideas on what is going on or how pytest-xdist works to help understand the issue would be greatly appreciated.
Thanks!
Here's a snippet of my output:
platform darwin -- Python 2.7.6 -- pytest-2.5.1 --
plugins: xdist
[gw0] darwin Python 2.7.6 cwd: /tests/unit_tests
[gw1] darwin Python 2.7.6 cwd: /tests/unit_tests
[gw2] darwin Python 2.7.6 cwd: /tests/unit_tests
[gw3] darwin Python 2.7.6 cwd: /tests/unit_tests
[gw0] Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) -- [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
[gw2] Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) -- [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
[gw1] Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) -- [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
[gw3] Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) -- [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
gw0 [30] / gw1 [30] / gw2 [30] / gw3 [30]
scheduling tests via LoadScheduling
test_save_load.py:17: test_exceptions
test_save_load.py:135: test_save_load[obj0]
test_save_load.py:45: test_gnome_obj_reference
test_save_load.py:135: test_save_load[obj2]
[gw3] PASSED test_save_load.py:17: test_exceptions
[gw1] PASSED test_save_load.py:45: test_gnome_obj_reference
test_save_load.py:31: test_reference_object
[gw3] PASSED test_save_load.py:31: test_reference_object
test_save_load.py:73: test_savloc_created
test_save_load.py:135: test_save_load[obj4]
[gw1] PASSED test_save_load.py:73: test_savloc_created
test_save_load.py:135: test_save_load[obj5]
[gw3] PASSED test_save_load.py:135: test_save_load[obj4]
test_save_load.py:135: test_save_load[obj6]
[gw2] FAILED test_save_load.py:135: test_save_load[obj2]
[gw0] FAILED test_save_load.py:135: test_save_load[obj0]
xdist output is a little different than standard's pytest because the tests are running in parallel. When you see:
test_save_load.py:135: test_save_load[obj0]
it means that the test has been sent to one of the nodes for execution.
When you see:
[gw0] FAILED test_save_load.py:135: test_save_load[obj0]
it just means that the test has finished in node 0.
That being said, your tests are being executed only once. Your description of the test failure seems to indicate that the tests are sharing some disk resource (for instance, they are all trying to write to the same file name).
You should make sure that your tests that deal with files work in separate directories so each test is completely isolated from the others; you can accomplish that with the help of the tmpdir fixture.
If you post more information about the test themselves perhaps people can give more specific advice.
Cheers,
Related
I am working on the Scala JS Tutorial located at: https://www.scala-js.org/doc/tutorial/basic/index.html which also links to the Repo: https://github.com/scala-js/scalajs-tutorial
So far I get through Step 5. The sample works well when you do:
sbt
~fastLinkJS
So when I run the run command that is where I have problems ( Starting Step 6 ). Node if you are using the Github Repo, make sure you update build.properties SBT version to 1.7.1 ( thats the version I have ).
When I then use the RUN command from within SBT, it will give the error I run into. So i can confirm it is reproducible.
I was not sure if it is also related to my machine. My statics are below:
uname -a:
Darwin HQSML-1689569 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64
node --version:
v12.4.0
sbt -version:
sbt version in this project: 1.7.1
sbt script version: 1.7.1
scala -version:
Scala code runner version 3.1.3 -- Copyright 2002-2022, LAMP/EPFL
Is this a current bug? Is this a ScalaJS thing? I was curious if it has lagged behind in comparison to javascript or something and it just fails to understand what the ?. statement means. Nothing is wrong with the jsdom module from what I can tell when looking at the JS itself, so i am thinking it is related to the Interpreter or something?
This is something like the question WinDbg: Version mismatch of dbghelp.dll when trying to attach to a process
However, I can't post to that question and the marked answer isn't really an answer and doesn't work for me.
I have a machine which I used to use for debugging crash dumps, but suddenly it fails to open any dumps, always reporting
dbghelp.dll has a version mismatch with the debugger
Microsoft (R) Windows Debugger Version 10.0.14321.1024 X86
Copyright (c) Microsoft Corporation. All rights reserved.
command line: '"C:\Program Files (x86)\Windows Kits\Debuggers\x86\windbg.exe" -c ".cmdtree c:\cmdtree.txt"
dbgeng: image 10.0.14321.1024, built Sat Jul 16 09:31:09 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbgeng.dll]
dbghelp: image 10.0.14321.1024, built Sat Jul 16 09:29:50 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbghelp.dll]
DIA version: 40116
So it's complaining of a mismatch, but there is no apparent mismatch.
The version of dbghelp and dbgeng in System32 and SysWOW64 is 6.1.7601.17514. But note that:
a) According to Microsoft page on DbgHelp, the version in Windows and WinDbg does not need to be (and probably shouldn't be) synced
b) I have another machine where I have installed 10.0.14321.1024 version of WinDbg, and it also has version 6.1.7601.17514 of dbghelp and dbgeng in Windows folders, and everything's working fine on that machine.
Any assistance appreciated.
This machine is basically bricked as far as analyzing crash dumps is concerned. I've tried reinstalling windbg, and installing different versions, still the same error occurs.
I have a Program.dll which I execute with Nunit GUI Runner on windows 7. Works perfect. The [Test] method is static.
When I execute it through bash in linux, in the XML it says :
signature is not correct: it must be an instance method.
here is the method declaration
[Test]
static public void NUnitWriter()
why does it work in windows with the Nunit GUI runner but not with it's linux console counterpart?
It's possible you're using an older version of the console application; static test methods weren't supported until version 2.5. You can check the version by running
> nunit-console.exe /?
NUnit-Console version 2.6.4.14350
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
...
If it's 2.4 or earlier, that's your problem.
please help me:
I run nunit in in the windows console.
After more than 300 tests the programm hangs. I don't konw why.
C:\Projekte\Sochi2014_TP_testing\reporting>"NUnit 2.6"\bin\nunit-console.exe /la
bels /out=NUnitTestResult.txt /xml=NUnitTestResult.xml ..\bin\x86\Debug\Sochi201
4_TP_testing.dll
NUnit-Console version 2.6.0.12051
Copyright (C) 2002-20011 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5456 ( Net 3.5 )
ProcessModel: Default DomainUsage: Single
Execution Runtime: net-3.5
Log4Net not configured. Looked for file: C:\Projekte\Sochi2014_TP_testing\bin\x8
6\Debug\log4net.config
More details for my issue:
I use selenium and specflow.
Nunit hangs up in a "Scenario Outline". The previous test runs normal. The browser (FF 13) is open and runs normal when I use the mouse.
My guess is that you have a test with a deadlock. You can add a timeout to NUnit:
nunit-console /timeout=10000 (other options as before)
This adds a 10 second timeout to each test. Then you should be able to see which test times out, and work out where the problem is. The number of tests shouldn't be an issue - my Noda Time project has thousands of tests which run without a problem, and I'm sure that's far from the biggest project using NUnit...
I have just updated my XCode to 3.2.4 and it turns out my unit tests are no longer working. I have configured a target and executable following the instructions from Scott Densmore so that I'm able to debug my tests.
I did change the Base SDK to iOS4.1 for my test target (LogicTests) and updated the path to the otest script for my executable (otest).
However, even though my application runs in the iPhone simulator, executing the unit tests always crashes. Here's what the console has to say when I try to run the tests:
[Session started at 2010-09-15 23:28:37 +0200.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys014
Loading program into debugger…
Program loaded.
run
[Switching to process 12125]
warning: The target crashed on startup, maybe the shell is crashing.
"Try set start-with-shell 0" to workaround.
The Debugger has exited due to signal 6 (SIGABRT).The Debugger has exited due to signal 6 (SIGABRT).
I'd appreciate any help you might be able to offer! Thanks in advance.
Cheers,
Georg
Totally just ran into this, too. Found I could get my tests to run by unchecking the DYLD_FORCE_FLAT_NAMESPACE environment variable. Seems to cause some awful problems. If I learn more on why, I'll post about it.