#c# #.net #visual-studio #unit-testing
#c# #.net #visual-studio #модульное тестирование
Вопрос:
Мне нравится создавать свои методы тестирования, такие как:
Should_not_allow_negative_number_in_value()
Но довольно скучно каждый раз вводить _ , к тому же у него всегда одна и та же подпись…
итак … кто-нибудь знает, как сделать это быстрее??
Спасибо!
Комментарии:
1. Серьезен ли этот вопрос? Если это так, я не понимаю, что вы имеете в виду. Пожалуйста, уточните.
2. @Codemonkey Что не так с этим вопросом? Конечно, это серьезно. Неужели так сложно понять, что @Carol хочет писать методы, в которых слова разделяются _ без необходимости написания _ ? Это может существовать. Например, что-то, что преобразует именование camelCase в это. Не знаю.
3. Я отредактировал свой вопрос об именовании. Не знаю, о чем я думал. Взгляните на это еще раз..
4. спасибо Оскар, я тестирую это здесь =)
Ответ №1:
Что-то, что могло бы автоматизировать (не совсем, но немного больше, если вы используете эту нотацию именования) этот процесс:
Обычно я называю свои тесты так:
MethodToTest_State_ExpectedBehavior
Пример:
[Test]
public void ConvertToInt32_NullValue_ThrowException
{
//Test method body
}
Вы можете установить ReSharper и создать новый живой шаблон, подобный:
[Test]
public void $Method$_$State$_$Expected$()
{
$END$
}
и укажите ярлык, подобный tst.
Теперь, каждый раз, когда вы хотите добавить новый метод, вам просто нужно начать писать tst и нажать TAB
два раза, и он создаст этот метод для вас, поместив курсор в Method
название. После того, как вы нажмете Enter
, курсор переместится в то место, где вы пишете State
имя, затем для Expected
, а затем оно будет помещено туда, где указано $END$
.
Редактировать:
Это тоже может быть полезно, если вы назовете все свои тесты с _Should
. Что-то вроде:
ConvertToInt32_NullValue_ShouldReturnTrue
Затем вы можете изменить свой шаблон, чтобы:
[Test]
public void $Method$_$State$_Should$Expected$()
{
$END$
}
Вы могли бы даже попытаться сгруппировать свои соглашения об именовании в несколько групп и создать фрагмент / шаблон для каждой из них.
Правка 2:
Подробнее об этом соглашении об именовании тестов: Стандарты именования для модульных тестов, автор Рой Ошеров, автор книги «Искусство модульного тестирования«.
Ответ №2:
Используйте более короткие имена и не пишите предложения в имени метода, используйте что-то более похожее
DisallowNegativeValuesTest()
Ответ №3:
Если вы ищете читаемые тесты, посмотрите на Cucumber amp; Gherkin как на BDD-фреймворк.
Ответ №4:
Я знаю несколько способов упростить это: использовать AutoHotkey или использовать ReSharper LiveTemplates
Ответ №5:
используйте PascalCase вместо undercore_case
например
ShouldNotAllowNegativeNumberInValue();
ура, никаких подчеркиваний! Код теперь на 80% менее скучный.
Комментарии:
1. Я думаю, что это предпочтение. Я отлично читаю camelCasing, и часто лучше с такими длинными фразами, как эта, потому что _ часто убираю длину таких фраз за пределы экрана. Возможно, вы захотите рассмотреть возможность адаптации к camelCase, особенно с c #, поскольку это ожидаемая норма.
2. Ты действительно думаешь, что Кэрол? Любой другой метод, с которым сталкивается разработчик, будь то пользовательский код или код фреймворка, почти всегда исключает любые подчеркивания (за несколькими исключениями). Что делает этот незнакомый способ более читаемым для тех, кто привык к тому, что все по-другому?
3. хорошо .. я попробую, но однажды я видел в веб-трансляции, как имена тестов набирались с пробелами, и после возврата или чего-то подобного пробелы заменялись символом подчеркивания…
4. Джейми, я имею в виду, только для методов тестирования
5. Мне нравится называть методы тестирования такими, как @Carol. Я думаю, что это просто соглашение между программистами вашей команды и то, как вы чувствуете себя более комфортно по этому поводу. Кроме того, Рою Ошерове, автору книги » Искусство модульного тестирования «, тоже нравится этот способ :/