Jak używać assertRaises w próbnym teście testowym za pomocą inlineCallbacks

Question

Próbuję dowiedzieć się, jak napisać próbny przypadek testowy, który zapewnia zgłoszenie wyjątku.

Obecnie mam 2 proste metody testowania (sukces i porażka). Każda metoda zwraca wartość odroczoną, która już została wywołana przez funkcję zwrotną lub errback. Testowanie metody sukcesu działa dobrze. Podczas testowania metody niepowodzenia oczekuję, że będę w stanie stwierdzić, że wyjątek został podniesiony (przy użyciu assertRaises).

Jednak w przypadku niepowodzenia testu i uzyskać:

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

Kod jest w następujący sposób:

 
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) 

używam odpowiedniego podejścia w test_failure? Mogę użyć try ... złapać połączenie do self.o.failure, ale nie sądzę, że to podejście jest tak dobre, jak przy użyciu assertRaises.

Answer 1

Zastosowanie TestCase.assertFailure zamiast:

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

Począwszy Twisted 12.3, istnieje również TestCase.failureResultOf pomocnik:

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

a od 13.1 to API bierze dodatkowy argument i wykonuje wpisać sprawdzanie dla Ciebie:

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

To my eful dla testów, w których wieszDeferred już wystrzelił z wynikiem. Jeśli w momencie wywołania Deferred nie ma wyniku niepowodzenia, failureResultOf podnosi wyjątek powodujący niepowodzenia testu zamiast zwracać błąd.

To zadziała dobrze dla twojego kodu przykładowego i powinno być odpowiednie dla większości testów jednostkowych. Jeśli używasz wersji próbnej do napisania testów funkcjonalnych lub integracyjnych, w których trwają rzeczywiste prace asynchroniczne i nie wiesz, kiedy zostanie uruchomiony Deferred, musisz trzymać się pierwszego API, assertFailure.