Действительно ли я должен зарегистрировать свои методы модульного теста?

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

О да!

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

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

Для модульных тестов я обычно говорю, что я тестирую, и , как это тестируется. Ввод «Test for Class.someMethod» не очень помогает.

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

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

Обратите внимание, что если вы '

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

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

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

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

Рефакторинг теста - хорошая практика, вы ДОЛЖНЫ реорганизовать свои тесты на самом деле, иначе их станет невозможно поддерживать.

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

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

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

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

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

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

Выдает

ok 74 - compare_bitstrings - bs1 > bs2

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

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

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

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

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

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

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

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

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

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