Пример модульного тестирования в C #?

Question

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

Это юнит-тест?

начать код псевдо ...

CheckForDuplicateSubdomains(){
  get all users in DB with matching subdomains
  if greater than zero, fail test
}

PS: я использую ASP.NET MVC в C #

Answer 1

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

Написание модульных тестов перед написанием функции является частью методологии, называемой «Разработка через тестирование». В которой вы пишете только скелет функции, и сначала все юнит-тесты. Поэтому сначала все ваши тесты не пройдут (т.к. функция еще не запрограммирована). После этого вы программируете функцию, пока все тесты не пройдут.

Answer 2

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

 assertEqual(4, square(2));
 assertEqual(4, square(-2));
 assertEqual(0, square(0));

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

Answer 3

Да, ваш пример будет модульным тестом. Есть несколько причин, чтобы сначала создать тест. Во-первых, он действует как живая документация для вашего проекта. Он устанавливает поведение и ожидаемые результаты, которые должны помочь вам на самом деле реализовать ваш код (легче написать что-то, зная, что ему нужно делать и в основном, как это инициируется). Во-вторых, если вы напишете тест позже, вы с большей вероятностью напишете тест, который работает с уже написанным кодом, который вам не поможет. Определите, что должна делать единица кода, напишите тесты и напишите / исправьте код, чтобы он отражал поведение в тестах. Эта стратегия приводит к улучшению понимания и качества по мере развития вашего приложения.

Answer 4

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

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

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

Теория «Модульное тестирование» (и «Разработка через тестирование») должна облегчить головную боль в будущем, убедившись, что каждая единица кода выполняет именно то, что от нее ожидается.

Answer 5

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

Нет, вы совершенно правы.

Для модульных тестов важно протестировать как можно меньший кусок кода.

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

Ваше db-соединение может быть потеряно, sql неверно, ...

Если вы используете asp.net MVC, вам будет проще писать модульные тесты, чем если бы вы использовали обычный asp.net

Answer 6

В семействе фреймворков семейства xUnit существуют очень хорошо разработанные соглашения для модульного тестирования, изначально производные от jUnit. В этих рамках утверждение является основным средством проведения теста. В тестовом наборе цель состоит в том, чтобы убедиться, что 100% ваших утверждений верны.

Рассмотрим ваш пример.

CheckForDuplicateSubdomains(){
  get all users in DB with matching subdomains
  if greater than zero, fail test
}

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

testNoDuplicateSubdomains(){
}

В каждом тесте есть четыре фазы :

• настройка прибора,
• упражнение SUT,
• проверка результата и
• демонтаж светильника.

SUT - это «тестируемая система», которая обычно является одним из методов класса в вашем производственном коде.

testNoDuplicateSubdomains(){
  // fixture setup
  prepareDatabaseTestData()
  // exercise SUT, 
  SUT = new ProductionObject()
  result = SUT.getAllUsersWithMatchingSubDomains()
  // result verification and 
  assertEmpty(result) // or whatever makes sense
  // fixture teardown.  
  removeDatabaseTestData()
}

Как и во многих методах разработки программного обеспечения, для написания юнит-тестов требуется время. Хороший ресурс для изучения лучших практик - это xUnit Test Patterns от Gerard Meszaros.