• SetUpClass (CLS) can be used in unitTest, and class variables can be defined directly in setUpClass, and class variables can be called in the useful example method, note only the call
  • What do you mean by parallel universes between use case methods? It’s a variable defined in test0, even if it’s a class variable. Neither can be called directly from test1. Such as:
def test0(self):
	self.b = 5
def test1(self):
	pring self.b
Copy the code

So once this is running, it’s going to execute test0 first, but it’s going to get an error when it gets to test1 and there’s no B in the class variable at all as opposed to a normal class method, which can print b=5 and in the unitTest use case method, There is no way to force changes to class variables defined in setUpClass. Even if you change the value of a class variable, when this use case ends and another use case calls the class variable, the value of the class variable goes back to the beginning of the class. This is the case when the class variables are arbitrarily superimposed during execution or even loop execution within your use case method, but are initialized as soon as the use case execution ends. This is also different from ordinary classes.

The above mentioned loop through a use case method. When does this happen? Like when you write a decorator that fails and runs again. And then we count them in terms of n. This n is the class variable, the initial value is 0 and every time you do this use case, you increment the class variable by one. Then count the reruns. At this point, class variables really add themselves. But this use case exceeds the maximum number of reruns, regardless of failure or success. Class variables will all revert to 0. Other use cases will still count from 0 when rerouted. How to run again. And with setup/teardown look at my other blog post unitTest use case failed and rerun with Setup /teardown