Следует ли документировать методы модульного тестирования?

As это происходит с частными методами методы испытаний документации могут видеть только те, кто имеет доступ к исходному коду. Стоит ли тратить на это усилия?

под документацией я подразумеваю что-то вроде (но более описательное):

/// <summary>
///A test for SomeClass.SomeMethod
///</summary>
[TestMethod()]
public void SomeMethodTest()
{
}
8
tdd unit-testing

13 ответов

модульные тесты должны быть самоописательными, но всегда будут случаи, когда эта цель не может быть достигнута, и, таким образом, описание того, что было написано.

другими словами, попробуйте сделать модульные тесты, чтобы они не нуждались в документации, но если им это нужно, напишите!

14

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

13

О да!

даже если "у кого есть доступ к исходному коду" никогда не будет кем-то еще, кроме вас, это не будет тем же самым, что вы смотрите на него через год (или даже через месяц), поверьте мне на это :-)

5

вы должны документировать весь код.

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

2

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

без этого документация вам нужно будет выяснить, что делает тест из его имени и комментариев/кода в тесте.

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

2

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

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

1

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

1

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

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

комментарии, как я их вижу почти всегда признак того, что вы должны выполнить рефакторинг, что кусок кода, который нужно прокомментировать. Что касается производства код применяется для тестирования кода.

1

большинство модульных тестов не должны нуждаться в документации. Название должно дать понять, какой метод они тестируют, и дать указание на ожидаемые результаты. Код должен быть простым и понятным. Модульные тесты не должны реализовывать бизнес-правила, поэтому документирование "почему" обычно не требуется.

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

1

для MSTest (IDK, если NUnit имеет что-то подобное) полезно DescriptionAttribute для каждого метода тестирования, так как они отображаются на панели результатов тестирования в Visual Studio. Более читабельным, чем именования WhenThisHappenShouldHappenThis.

0

Я нахожу сообщение, распечатанное модульным тестом, когда оно выполняется, как правило, достаточно. Например, в Perl:

is(compare_bitstrings($bs1, $bs2, $gen), 1, 'compare_bitstrings - bs1 > bs2');

дает

ok 74 - compare_bitstrings - bs1 > bs2

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

0

абсолютно!! Модульные тесты должны быть документированы каждый бит, а также ваш фактический код. Если по какой-либо другой причине, кроме не редкого обстоятельства не зная, если это ваш код или ваш тест, который имеет ошибку.

0

когда я пишу тесты, я предпочитаю комментарий Для теста, а затем с описательным именем метода теста (например, формат S/S/R, упомянутый в комментариях другого ответа), потому что это привычка моих коллег разработчиков и я попал, когда мы начали с CPPUNIT с C++. Поскольку я балуюсь C#, точка, упомянутая Лукасом в его ответе, является хорошей - когда структура позволяет это, поле описания, которое можно использовать в исходном коде и результатах, очень удобно, и я бы предпочел комментарий формат, который можно использовать во многих местах, таких как это.

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

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

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

0