Более быстрое создание методов тестирования

#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. Я думаю, что это просто соглашение между программистами вашей команды и то, как вы чувствуете себя более комфортно по этому поводу. Кроме того, Рою Ошерове, автору книги » Искусство модульного тестирования «, тоже нравится этот способ :/