¿Persisten los cambios de variables entre pruebas en unittest?

¿Cómo puedo persistir los cambios realizados dentro del mismo objeto heredado de TestCase en unitttest?

 from unittest import TestCase, main as unittest_main class TestSimpleFoo(TestCase): foo = 'bar' def setUp(self): pass def test_a(self): self.assertEqual(self.foo, 'bar') self.foo = 'can' def test_f(self): self.assertEqual(self.foo, 'can') if __name__ == '__main__': unittest_main() 

Es decir: quiero que esas dos pruebas anteriores pasen

Como algunos comentarios se han hecho eco, estructurar sus pruebas de esta manera es probablemente una falla de diseño en las pruebas en sí mismas y debería considerar reestructurarlas. Sin embargo, si desea hacer esto y confía en el hecho de que el corredor de pruebas que está utilizando los ejecuta en orden alfabético (aparentemente), sugiero lo siguiente.

Similar a lo que dijo @Matthias, pero haría una cosa diferente para los casos en los que puede decidir heredar de la clase en una fecha posterior.

 from unittest import TestCase, main as unittest_main class TestSimpleFoo(TestCase): foo = 'bar' def setUp(self): pass def test_a(self): self.assertEqual(self.__class__.foo, 'bar') self.__class__.foo = 'can' def test_f(self): self.assertEqual(self.__class__.foo, 'can') if __name__ == '__main__': unittest_main() 

La diferencia entre esta respuesta y la respuesta de @ Matthias que aceptaste es la statement explícita de la clase frente a la búsqueda de dicha referencia de clase.

 TestSimpleFoo vs self.__class__ 

Prefiero la dinamismo para poder heredar las pruebas más adelante y ejecutar ambas clases de prueba una detrás de otra y no tener ningún cruce entre las dos. Porque si eligiera heredar de esta clase, nombrar explícitamente la referencia de clase causaría que ambas clases de prueba se ejecuten en esa referencia en lugar de sus propias clases respectivas.

Me gusta tu propia respuesta por la simplicidad de la misma, pero si quieres mantener pruebas unitarias distintas:

Al parecer, unittest ejecuta pruebas separadas con instancias nuevas de TestCase. Bueno, solo une los objetos para que sean persistentes a algo más que a uno mismo. Por ejemplo:

 from unittest import TestCase, main as unittest_main class TestSimpleFoo(TestCase): def setUp(self): pass def test_a(self): TestSimpleFoo.foo = 'can' def test_f(self): self.assertEqual(TestSimpleFoo.foo, 'can') if __name__ == '__main__': unittest_main() 

También le pueden interesar setUpClass y tearDownClass: https://docs.python.org/3/library/unittest.html#setupclass-and-teardownclass

También tenga cuidado con el orden de ejecución de sus pruebas de unidad: https://docs.python.org/2/library/unittest.html#unittest.TestLoader.sortTestMethodsUsing

No podía entenderlo; así que terminé hackeando con varias funciones prefijadas sin test_ :

 def test_password_credentials_grant(self): for user in self.user_mocks: self.register(user) self.login(user) self.access_token(user, self.assertEqual) # Ensures access_token is generated+valid self.logout(user) self.access_token(user, self.assertNotEqual) # Ensures access_token is now invalid self.unregister(user) 

Además de lo que otros dijeron, el intercambio de datos entre los métodos de prueba no debería implementarse de esta manera, se recomienda usar setup ().

El método de prueba en sí debe ser aislado.