Написание длинных имен методов тестирования для описания тестов по сравнению с использованием в документации кода

Question

Для написания юнит-тестов я знаю, что очень популярно писать методы тестирования, которые выглядят как

public void Can_User_Authenticate_With_Bad_Password()
{
...
}

Хотя это позволяет легко увидеть, для чего тестирует тест, я думаю, что он выглядит некрасиво и плохо отображается в автоматически сгенерированной документации (например, sandcastle или javadoc).

Мне интересно посмотреть, что люди думают об использовании схемы именования, которая является тестируемым методом и подчеркивает тест, а затем номер теста. Затем используйте документ XML-кода (.net) или комментарии javadoc для описания того, что тестируется.

/// <summary>
/// Tests for user authentication with a bad password.
/// </summary>
public void AuthenticateUser_Test1()
{
...
}

выполнив это, я легко могу сгруппировать свои тесты по методам, которые они тестируют, я могу увидеть, как я могу провести тестирование по данному методу, и у меня все еще есть полное описание того, что тестируется.

у нас есть несколько регрессионных тестов, которые запускаются против источника данных (файл xml), и этот файл может быть обновлен кем-то без доступа к исходному коду (обезьяна QA), и они должны быть в состоянии прочитать то, что тестируется и где обновлять источники данных.

Answer 1

Я предпочитаю версию "длинных имен" - хотя только для описания , что происходит . Если для теста требуется описание , почему это происходит, я добавлю это в комментарий (с номером ошибки, если необходимо).

С длинным именем гораздо яснее, что пошло не так, когда вы получаете письмо (или что-то еще), сообщающее вам, какие тесты не пройдены.

Я бы написал это в терминах того, что должен сделать, хотя:

LogInSucceedsWithValidCredentials

LogInFailsWithIncorrectPassword

LogInFailsForUnknownUser

Я не согласен с аргументом, что он выглядит плохо в автоматически сгенерированной документации - почему вы запускаете JavaDoc поверх тестов , во-первых? Я не могу сказать, что когда-либо делал это, или хотел сгенерированную документацию. Учитывая, что методы тестирования обычно не имеют параметров и ничего не возвращают, если имя метода может их разумно описать, это все, что вам нужно. Бегущий по тестам должен быть в состоянии перечислить тесты, которые он выполняет, или IDE может показать вам, что доступно. Я нахожу это более удобным, чем навигация по HTML - в браузере нет «Find Type», который позволяет мне набирать только первые буквы каждого слова имени, например ...

Answer 2

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

Лично я предпочитаю длинные имена и редко вижу необходимость добавлять комментарии к тестам.

Answer 3

Я сделал свою диссертацию на смежную тему, так что вот мои два цента: всякий раз, когда вы полагаетесь на документацию для передачи чего-то, чего нет в сигнатуре вашего метода, вы берете на себя огромный риск, что никто не будет читать документацию .

Когда разработчики ищут что-то конкретное (например, сканируют длинный список методов в классе, чтобы увидеть, есть ли там то, что они ищут), большинство из них не собираются читать документацию. Они хотят иметь дело с одним типом информации, которую они могут легко увидеть и сравнить (например, имена), вместо того, чтобы начинать перенаправлять на другие материалы (например, зависать достаточно долго, чтобы увидеть JavaDocs).

Я бы настоятельно рекомендовал передать все, что имеет отношение к вашей подписи.

Answer 4

Я предлагаю меньшие, более сфокусированные (тестовые) классы.

Зачем вам тесты Javadoc?

Answer 5

Лично я предпочитаю использовать длинные имена методов. Обратите внимание, что вы также можете иметь имя метода внутри выражения, как:

Can_AuthenticateUser_With_Bad_Password()

Answer 6

Как насчет изменения

Can_User_Authenticate_With_Bad_Password

до

AuthenticateDenieTest
AuthenticateAcceptTest

и название устраивает что-то вроде User

Answer 7

Как группа, как мы относимся к созданию гибридной схемы именования, подобной этой

/// <summary>
/// Tests for user authentication with a bad password.
/// </summary>
public void AuthenticateUser_Test1_With_Bad_Password()
{
...
}

и мы получаем лучшее из обоих.