Cómo utilizar assertRaises en un caso de prueba de prueba utilizando inlineCallbacks

Question

Estoy tratando de averiguar cómo escribir un caso de prueba de prueba que afirma que se produce una excepción.

Actualmente tengo 2 métodos simples para probar (éxito y fracaso). Cada método devuelve un diferido que ya ha sido devuelto o revertido. Probar el método de éxito funciona bien. Al probar el método de falla, espero ser capaz de afirmar que se produjo una excepción (usando assertRaises).

Sin embargo, el caso de prueba falla y me sale:

 
twisted.trial.unittest.FailTest: ConnectionRefusedError not raised (<Deferred at 0x920e28c current result: <twisted.python.failure.Failure <class 'twisted.internet.error.ConnectionRefusedError'>>> returned) 

El código es el siguiente:

 
from twisted.trial.unittest import TestCase 
from twisted.internet.defer import inlineCallbacks, succeed, fail 
from twisted.internet.error import ConnectionRefusedError 

class MyObject: 
    def success(self): 
     return succeed(True) 

    def failure(self): 
     return fail(ConnectionRefusedError()) 


class TestErrBack(TestCase): 
    def setUp(self): 
     self.o = MyObject() 

    @inlineCallbacks 
    def test_success(self): 
     result = yield self.o.success() 
     self.assertTrue(result) 

    @inlineCallbacks 
    def test_failure(self): 
     # this test case is failing ! 
     yield self.assertRaises(ConnectionRefusedError, self.o.failure) 

estoy usando el enfoque correcto en test_failure? Puedo usar try ... tomar la llamada a self.o.failure, pero no creo que este enfoque sea tan bueno como usar assertRaises.

Answer 1

Uso TestCase.assertFailure lugar:

yield self.assertFailure(self.o.failure(), ConnectionRefusedError) 

A partir de Twisted 12.3, también hay un ayudante TestCase.failureResultOf:

self.failureResultOf(self.o.failure()).trap(ConnectionRefusedError) 

Y a partir de 13.1 esta API toma un argumento adicional y lleva a cabo una verificación de tipos para usted:

self.failureResultOf(self.o.failure(), ConnectionRefusedError) 

This is us eful para pruebas donde sabe el Deferred ya ha disparado con un resultado. Si el Deferred no tiene un resultado de falla en el momento de la llamada, failureResultOf genera una excepción de falla de prueba en lugar de devolver el error.

Esto funcionará bien para su código de ejemplo y debería ser aplicable a la mayoría de las pruebas unitarias. Si está utilizando una versión de prueba para escribir pruebas funcionales o de integración en las que hay un trabajo asincrónico real y no sabe cuándo se activará el Deferred, debe seguir con la primera API, assertFailure.