invoke setUpClass() many times under running multiple cpu mode

[heipark]

os: win7
py:2.7 && pytest (2.8.2) && pytest-xdist (1.13.1)

import unittest

class SomeTest(unittest.TestCase):

    def test_unit1(self):
        pass

    def test_unit2(self):
        pass

    def test_unit3(self):
        pass

    def test_unit4(self):
        pass                        

    def test_unit4(self):
        pass         

    def test_unit5(self):
        pass     

    @classmethod
    def setUpClass(cls):
        with open('c:/abc.txt', 'a') as f :
            f.write('######\n')

command：

py.test testme.py   -v -n 3

content of c:/abc.txt:

######
######
######

xdist can not guarantee setUpClass() only run once ?

[spinus]

It's one per process. So how it works is, xdist takes all the tests and split them into 3 test sets, and set up function is executed for each set.
It's like that for example because tests can be executed on remote hosts and than you want to run set up.

In you case I think this is badly written test. I think you should use https://docs.python.org/2/library/tempfile.html to create test file/directories and remove them at tear_down, or better, there are some fixtures which helps with that (https://pytest.org/latest/tmpdir.html)

[RonnyPfannschmidt]

that's working as designed

[heipark]

hello spinus

in my scenario, I want to insert data to database in setUpClass() in every test case. Repeatedly calling the method will lead to data chaos :(
How to solve this problem?

thx

[heipark]

i found this topic, maybe i can try the solution of @piwai by using ClassLoadScheduling

"way to control how pytest-xdist runs tests in parallel? #175"
pytest-dev/pytest#175

[heipark]

i fork xdist and merge @piwai code，and fix problem，now it works.

https://github.com/heipark/pytest-xdist

[spinus]

@heipark why not just isolate the tests? You can create database in setup method (with worker number in the name)

[RonnyPfannschmidt]

that fork looks interesting

[RonnyPfannschmidt]

its solving a completely different problem that incidentially solves the problem @heipark has due to distribution strategies

[nicoddemus]

I have been working on the background on writing up a more generic proposal on controlling how xdist distributes the test across slaves in --dist=load, checkout #17.

[heipark]

@spinus how to get worker name (subprocess name ?) in setUp() and test method?

thx

[namgivu]

@spinus how to get worker name (subprocess name ?) in setUp() and test method?

thx

Same with @heipark, how to get worker number/name?

[nicoddemus]

You can use an environment variable for that, I forget the name right now but it is in the readme