Повторное использование кода в модульных тестах?
-
21-12-2019 - |
Вопрос
Я постоянно слышу, как люди говорят о том, что тесты должны быть простыми, удобными в сопровождении и понятными, но что происходит с возможностью повторного использования кода при модульном тестировании?
Возьмем, к примеру:
def test_some_1():
...some code
def test_some_2():
...code repeated from test_some_1
Не лучше ли инкапсулировать повторяющийся код двух тестов в функцию, содержащую необходимые утверждения?
Я спорил по этому поводу с некоторыми программистами, и они не соглашались, говорили, что тесты должны быть тупыми, что повторное использование кода здесь нехорошо.Причина этого в том, что в консоли django не очень ясно, где утверждение на самом деле не удалось, потому что утверждение было в функции, хотя я не согласен, потому что использование его с носом даст вам имя теста и обратную трассировку, хотя Ребята снова не согласились, заявив, что тест можно вызвать индивидуально, без носа (и поэтому вы не сможете увидеть все эти детали).
Ребята, что вы думаете?
- Хорошо ли использовать возможность повторного использования кода в модульных тестах?
- Если возможность повторного использования может/должна использоваться, то как преодолеть другую проблему, связанную с определением утверждений?
Решение
Наиболее важные факторы качества кода, такие как ясность и читаемость, также важны для тестового кода.Если повторение кода облегчает чтение, вам следует делать это независимо от того, пишете ли вы тестовый код, и наоборот.
Например, в одном пакете, который я написал, у меня была функция:
def _test_vector(self, a, b, c):
# test the function with parameter values a, b, c
# several asserts here to verify output of function tested
Это позволило записать все тестовые векторы следующим образом:
def test_vector1(self):
self._test_vector(a=42, b=5, c="blah)
Это, по моему мнению, повышает ясность, поскольку отдельные тесты включают только информацию, специфичную для этого теста.
Выявлять утверждения всегда должно быть легко.Даже unittest
предоставит вам обратную трассировку, и если ваша настройка тестирования не указывает на конкретное утверждение, вам будет сложно отлаживать любые неудачные тесты, и вам обязательно следует переключиться на что-то разумное.
Другие советы
Как сказал ваши сверстники, вы должны написать свои тесты глупыми.Для этого есть несколько причин, тем самым важным является то, что вы хотите избежать сложной логики в тестах.Если вы пишете свои тесты «умные», они имеют тенденцию содержать ту же или похожую логику, что и код, который вы пытаетесь проверить.Это означает, что вы рискуете делать ту же ошибку в обоих местах, так и пропустить ошибки, которые вы хотите найти.
Другой причиной в том, что вы хотите, чтобы ваш тест выступил в качестве документации кода, который вы пытаетесь проверить.Если тест имеет сложный путь выполнения через множество функций и логики, он не будет так легко понять.В лучшем из миров вы бы увидили, как производственный код предназначен для работы, просто оглядываясь на тест.