Я вижу проблему в своем тестовом наборе в суде, где все работает нормально, пока я не получу тайм-аут. Если тест не удается из-за тайм-аута, функция tearDown никогда не вызывается, оставив реактор нечистым, что, в свою очередь, приводит к сбою остальных тестов. Я считаю, что tearDown следует вызывать после таймаута, кто-нибудь знает, почему это может случиться?tearDown не вызывается после таймаута в скрученной пробной версии?
Вы правы, что tearDown() следует называть независимо от того, что происходит в вашем тесте. От the documentation для tearDown():
Это называется даже если тестовый метод поднял исключение
Тем не менее, есть улов. Из той же документации:
Этот метод вызывается только в том случае, если setUp() преуспевает, независимо от результата тестового метода.
Так это звучит, как вы, возможно, запустить реактор в setUp() и когда это тайм-аут, это предотвращения своего tearDown() от бега - идея в том, что бы вы ни пытались «настроить» в setUp() был не успешно настроена, поэтому вы не хотите пытаться снести ее. Однако было бы трудно диагностировать с уверенностью, если вы не предоставите код своих методов setUp и tearDown, а также код любых соответствующих тестов.
Это довольно странно, потому что на моей коробке разрывы выполняются, даже если происходит таймаут. Испытания должны прекратиться, если реактор не находится в чистом состоянии, если вы не используете флаг --unclean-warnings. Остается ли тестовый бегун после тайм-аута для вас? Какую версию Python и Twisted вы используете?
В качестве побочного примечания, если вам нужно запустить уникальный отрыв для конкретной тестовой функции, есть очень удобный обратный вызов addCleanup(). Это пригодится, если вам нужно отменить функции обратного вызова, LoopingCall или callLater, чтобы реактор не находился в грязном состоянии. addCleanup возвращает Deferred, так что вы можете просто вызвать обратные вызовы, выполняющие adhoc teardown. Это может быть хорошим вариантом попробовать, если классный срыв не работает на вас.
PS
Я так привык писать «хорошо себя ведет» Twisted код, я даже не помню, как попасть в нечистом состоянии реактора: D Я клянусь, я не хвастаюсь. Не могли бы вы дать мне краткий обзор того, что вы делаете, чтобы я мог проверить это на моем конце?
Я нашел проблему, я поставлю ее здесь, если она будет полезной для кого-либо еще в будущем.
Я возвращал отложенное из теста, которое уже было вызвано (как и в случае с отложенным вызовом), но у него все еще была незавершенная цепочка обратного вызова. Из того, что я вижу в пробном коде здесь https://github.com/twisted/twisted/blob/twisted-16.5.0/src/twisted/trial/_asynctest.py#L92, реактор разбивается, когда это происходит, что объясняет, почему tearDown не вызван. Решение для меня состояло в том, чтобы вернуть отсроченные тесты, которые не имеют цепочку обратного вызова, которая живет в течение длительного времени (это обратные вызовы не возвращают отложенные сами).
Есть ли способ узнать, не сбит ли setUp? Похоже, что он успешно завершает работу и переходит к тесту.Тогда это терпит неудачу в тесте и tearDown никогда не называется – ppao
Ли время ожидания вызывает исключение? Если это так, вы можете попробовать поймать это исключение. Но это трудно сказать, не видя метода. Не могли бы вы добавить код вашего метода 'setUp' к вашему вопросу? – elethan