Почему утверждения в unittest используют TestCase.assertEqual, а не ключевое слово assert?
Встроенный модуль unittest для Python делает утверждения с помощью методов TestCase.assert*
:
class FooTest(TestCase):
def test_foo(self):
self.assertEqual(1,1)
self.assertNotEqual(1,2)
self.assertTrue(True)
Я обычно использовал testrunner, например nose или py.test, которые позволяют использовать встроенное ключевое слово assert
при создании утверждений:
assert 1 == 1
assert 1 != 2
assert True
Какова мотивация подхода unittest TestCase.assert*
и каковы сильные и слабые стороны этого против утверждения со встроенным ключевым словом assert? Существуют ли причины, по которым должен поддерживаться синтаксис unittest?
Ответы
Ответ 1
Проблема с ключевым словом assert
заключается в том, что она оптимизирована и, таким образом, игнорируется, когда Python запускается в "оптимизированном" режиме (с аргументом -O
или с набором переменных среды PYTHONOPTIMIZE
). Если тесты должны были использовать assert
, тогда тестирование с помощью -O
было бы невозможным.
Кроме того, использование методов assert делает тривиальным сообщать о том, какие фактические значения были на самом деле, без необходимости вникать в стек и источник и выяснить, какими они должны были быть (что, я считаю, является для этого используются техника nose
и py.test
.)
Ответ 2
Я не вижу конкретного конструктивного решения для этого. Глядя на unittest docs, он заявляет
что
будет вызвана функция определенного типа типа, чтобы генерировать более полезное сообщение об ошибке по умолчанию
Поэтому я бы сказал, что это решение для реализации, чтобы помочь создавать более значимые ошибки и т.д.
Ответ 3
Основная сила этого подхода заключается в предоставлении нескольких встроенных тестов, которые обычно выполняются так, что им не нужно писать их снова и снова. Кроме того, assertRaises позволяет настраивать точное поведение assert, вызывая исключение.