Пример поблочного тестирования в C#?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

testNoDuplicateSubdomains(){
}

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

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

SUT - это "

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

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

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

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

Ваше соединение с базой данных может быть потеряно, sql invalid, ...

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