xunit vs multiprocess

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run xunit unit test w/ --processes=2
2. See fails

What is the expected output? What do you see instead?

All of nose's tests should pass under --processes=2

Please use labels and text to provide additional information.

Problem is, xunit creates a file and writes to it when it sees reportable 
events. For that to work 
under mp, all the reporting has to happen in the main process. That will 
require a major redesign of 
how mp worker processes report their results to the main process.

Original issue reported on code.google.com by jpelle...@gmail.com on 16 May 2009 at 1:04

[GoogleCodeExporter]

Any update to this issue?  I would love to see a fix soon as this issue is 
plaguing me.  

Original comment by boneill...@gmail.com on 22 Dec 2010 at 10:50

[GoogleCodeExporter]

I don't have time to work on nose myself right now, but would happily accept a 
patch (with tests) that fixes this issue.

Original comment by jpelle...@gmail.com on 23 Dec 2010 at 2:19

[GoogleCodeExporter]

I wish I had the knowledge to fix it myself.  

Original comment by boneill...@gmail.com on 27 Dec 2010 at 6:59

[GoogleCodeExporter]

I was able to do a quick fix using multiprocessing.Queue and 
multiprocessing.Array to manage passing data across the processes. Because the 
multiprocess plugin also uses the python multiprocessing module, this seemed 
like the most natural extension. 

In order for this work, the xunit plugin also needs to be loaded into each new 
process, this is currently not being done in the mulitprocess plugin.

I'm attaching two files: a new multiprocess plugin and xunit plugin called 
Xunitmp:

The multiprocess plugin also fixes the timeouts, generator issues as covered in 
Issue 399:

http://code.google.com/p/python-nose/issues/detail?id=399

The Xunitmp plugin can be enabled with --with-xunitmp

The only disadvantage here is that the queues are global variables. I don't 
think this will be a problem...

rosen diankov,

Original comment by ffxvzero@gmail.com on 23 Feb 2011 at 11:18

Attachments:

• multiprocess.py
• xunitmultiprocess.py

[GoogleCodeExporter]

I'm attaching a new version of xunitmultiprocess.py that accurately measures 
the timings.

rosen diankov,

Original comment by ffxvzero@gmail.com on 23 Feb 2011 at 12:02

Attachments:

• xunitmultiprocess.py

[GoogleCodeExporter]

Original comment by jpelle...@gmail.com on 23 Feb 2011 at 1:21

• Added labels: Patch-New

[GoogleCodeExporter]

I'm attaching a new version of xunitmultiprocess

After doing a little more testing, it became clear that multiprocessing.Manager 
is a better alternative than multiprocessing.Queue since it doesn't block on 
exiting processes.

I also made it play nicer with the Capture plugin, now it will fill the 
<system-out> XML tags instead of embedding it into the error stream.

Original comment by ffxvzero@gmail.com on 25 Feb 2011 at 5:35

Attachments:

• xunitmultiprocess.py

[GoogleCodeExporter]

Please get the latest xunitmultiprocess.py from:

https://openrave.svn.sourceforge.net/svnroot/openrave/trunk/test/noseplugins/xun
itmultiprocess.py

In order to use it with the new multiprocess.py, have to do:

multiprocess._instantiate_plugins = [xunitmultiprocess.Xunitmp]

Original comment by rosen.di...@gmail.com on 25 Mar 2011 at 5:51

[GoogleCodeExporter]

Rosen:

I'm glad to see you're using Manager.Queue rather than the raw Queue. 

It's troubling to see coupling between the multiprocess and xunit plugins. They 
shouldn't *need* to be aware of each other.

Earlier, I added a fix to the plugintest plugin which may have some bearing 
here. The cleanest solution was to always use multiprocessing-aware interface 
whenever the the multiprocessing module was available. This meant that the 
plugintest system didn't need to be aware of the multiprocess plugin, and vice 
versa. It would continue to "just work" regardless of whether multiprocessing 
was used or not.

Would an analogous approach be useful here?

Original comment by workitha...@gmail.com on 3 May 2011 at 4:09

[GoogleCodeExporter]

does the new multiprocess code already address this issue?  Some (maybe all) of 
the patches here have been applied already in Issue 399

Original comment by kumar.mcmillan on 3 May 2011 at 2:38

• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

I tried it today but the problem is still there and was not fixed by Issue 399.

As far as I understand it after trying a few things each test process creates 
its own 
Xunit instances, then report, addSucess, addFailure and so on gets called on 
different
instances. As suggested in previous comments I guess it could be solved by 
sharing
same instance of the errorlist. I don't see the need of this affecting the 
multiprocess plugin at all, but maybe I am missing something?

Original comment by anders.r...@gmail.com on 22 Nov 2011 at 2:07

[GoogleCodeExporter]

Ok, I see now why you need to add things in the multiprocess plugin, I thought 
the multiprocessing module worked differently.

Original comment by anders.r...@gmail.com on 22 Nov 2011 at 2:40

[GoogleCodeExporter]

Hi I have a question about nosetests --multiprocess=3. I wrote a simple test 
with three test cases. The tests run fine:

donald@donald-VirtualBox:~/source/csbu-qa/AutomatedTests/python_tests/hp_accepta
nce/sample (qa-current)$ nosetests -v -s test_parallel_sample.py --processes=2 
--with-xunit --process-restartworker
testSample1[1]
testSample2[1]
testSample1 
(python_tests.hp_acceptance.sample.test_parallel_sample.SampleTestClass) ... ok
testSample2 
(python_tests.hp_acceptance.sample.test_parallel_sample.SampleTestClass) ... ok
testSample3[1]
testSample3 
(python_tests.hp_acceptance.sample.test_parallel_sample.SampleTestClass) ... ok

but when I try to output to an xml file with --xunit I get <?xml version="1.0" 
encoding="UTF-8"?><testsuite name="nosetests" tests="0" errors="0" failures="0" 
skip="0"></testsuite> each time

How do I get it output the correct result?

Original comment by donald...@gmail.com on 6 Sep 2012 at 7:15

[GoogleCodeExporter]

@donald The xunit + multiprocess issue isn't fixed. Did you try your sample 
with Rosen's xunitmultiprocess plugin from comment 8? 
http://code.google.com/p/python-nose/issues/detail?id=267#c8

Original comment by w...@policystat.com on 6 Sep 2012 at 7:38

[GoogleCodeExporter]

I'm trying the use of Rosen's plugin for some of my integration tests. The 
first problem I had was that its options --xunit-file conflicts with xunit 
plugin's option of the same name. So I changed Rosen's plugin to have 
--xml-file instead and got it working. Secondly, my tests do not have an 
attribute capturedOutput which the plugin refers to:

        if test.capturedOutput is not None:
            systemout = '<system-out><![CDATA['+escape_cdata(str(test.capturedOutput))+']]></system-out>'
        xml = """<testcase classname=%(cls)s name=%(name)s time="%(taken)f">

I've commented out the if condition for now and kicked off a run. Will report 
back any issues I see. Would love to very much see this plugin/ this issue 
fixed. The multiprocess runs saved 1/3rd of our run time but not having jenkins 
reports doesn't go down well with the management :(

Original comment by srivatsa...@gmail.com on 12 Nov 2012 at 12:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I did the following steps:

Downloaded

multiprocess.py and xunitmultiprocess.py and put these files in:

/usr/local/lib/python2.7/dist-packages/nose-1.2.1-py2.7.egg/nose/plugins

where do I need to put multiprocess._instantiate_plugins = 
[xunitmultiprocess.Xunitmp] to make it work?

Original comment by donald...@gmail.com on 17 Nov 2012 at 12:08

[GoogleCodeExporter]

Hi there,

It must be obvious for the most of the people but I really don't get where do I 
have to put multiprocess._instantiate_plugins = [xunitmultiprocess.Xunitmp]

Original comment by evgeny.m...@gmail.com on 26 Dec 2013 at 6:44