Вопрос

Я постоянно слышу, как люди говорят о том, что тесты должны быть простыми, удобными в сопровождении и понятными, но что происходит с возможностью повторного использования кода при модульном тестировании?

Возьмем, к примеру:

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 предоставит вам обратную трассировку, и если ваша настройка тестирования не указывает на конкретное утверждение, вам будет сложно отлаживать любые неудачные тесты, и вам обязательно следует переключиться на что-то разумное.

Другие советы

Как сказал ваши сверстники, вы должны написать свои тесты глупыми.Для этого есть несколько причин, тем самым важным является то, что вы хотите избежать сложной логики в тестах.Если вы пишете свои тесты «умные», они имеют тенденцию содержать ту же или похожую логику, что и код, который вы пытаетесь проверить.Это означает, что вы рискуете делать ту же ошибку в обоих местах, так и пропустить ошибки, которые вы хотите найти.

Другой причиной в том, что вы хотите, чтобы ваш тест выступил в качестве документации кода, который вы пытаетесь проверить.Если тест имеет сложный путь выполнения через множество функций и логики, он не будет так легко понять.В лучшем из миров вы бы увидили, как производственный код предназначен для работы, просто оглядываясь на тест.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top