Я хочу научиться писать тестовые примеры, прежде чем писать код. Я прочитал статью о разработке через тестирование. Интересно, как разработчики пишут тестовые случаи? Например, этот метод:
public int divideNumbers(int num1, int num2)
{
return num1 / num2;
}
Начнем с пустого проекта. Вы хотите что-то сделать, скажем, разделить два числа. Итак, вы пишете тест, описывающий, что вы хотите сделать:
Assert.That(divide(10,2), Eq(5))
Этот тест дает вам точку входа: он описывает приемлемый интерфейс метода divide. Итак, вы переходите к реализации, например, как int divide(int x, int y).
Напишите тесты, которые описывают, что вы ожидаете получить от своего кода. Вам не нужно много думать об этом. Самый обычный способ записи ваших ожиданий, вероятно, является лучшим способом разработки вашего кода, а затем вы можете реализовать его, чтобы он удовлетворял вашему тесту.
Есть несколько шагов для тестирования. От 1_;
В твоем случае;
Assert.AreEqual(divideNumbers(8, 4), 2);
Класс Assert проверяет условия в модульных тестах, используя предложения true/false. Вы должны написать свои тестовые случаи, что вы ожидаете от их результатов. Вы можете использовать атрибут TestMethod для своих методов тестирования. Есть отличный пост о создании модульных тестов для вашего код С#. Проанализируйте это очень хорошо.
Начните с заглушки функции/класса/компонента, который вы хотите разработать. Он должен компилироваться, но намеренно (пока) не делать то, что должен делать.
Например:
public int divideNumbers(int num1, int num2)
{
throw new NotImplementedException();
}
or
return -42;
Подумайте о предполагаемом поведении, рассматривая заглушку как интерфейс к черному ящику. Плевать на реализацию (пока). Подумайте о «контракте» интерфейса: X входит, Y выходит.
Определите стандартные случаи и важные случаи egde. Напишите для них тесты.
Для целочисленного деления (при условии, что мы напишем его с нуля) на самом деле нужно рассмотреть несколько случаев: с остатком и без остатка, n/1, n/0, 0/n, 0/0, отрицательные числа и т. д.
Assert.IsTrue(divideNumbers(4,4) == 1);
Assert.IsTrue(divideNumbers(4,3) == 1);
Assert.IsTrue(divideNumbers(4,2) == 2);
Assert.IsTrue(divideNumbers(4,1) == 4);
Assert.Throws<ArgumentException>(() => divideNumbers(4,0));
Assert.IsTrue(divideNumbers(0,4) == 0);
Assert.Throws<ArgumentException>(() => divideNumbers(0,0));
Assert.IsTrue(divideNumbers( 4,-2) == -2);
Assert.IsTrue(divideNumbers(-4, 2) == -2);
Assert.IsTrue(divideNumbers(-4,-2) == 2);
Assert.IsTrue(divideNumbers( 4,-3) == -1);
Assert.IsTrue(divideNumbers(-4, 3) == -1);
Assert.IsTrue(divideNumbers(-4,-3) == 1);
Скомпилируйте и запустите модульные тесты. Все ли они терпят неудачу? Если нет, то почему? Возможно, один из тестов не работает должным образом (тесты тоже могут глючить!).
Теперь приступайте к реализации до тех пор, пока ни один тест больше не будет давать сбоев.
Начните с осознания разницы между теорией и практикой.
В любой реальной системе есть вещи, которые легко создаются с помощью TDD, а есть и такие, которые не создаются.
Последняя группа — это все, что зависит от среды, при работе над системой, которая не стремится абстрагироваться от допущений среды, а прагматично принимает их.
Эта группа может быть разработана в стиле TDD, но для этого потребуются дополнительные инструменты и расширения для фабрики программного обеспечения.
Для .Net это будут инструменты и расширения, такие как виртуальная тестовая лаборатория MS и SpecFlow.
Я пытаюсь сообщить, что это зависит.
Для очень простого компонентного/модульного тестирования идея заключалась бы в том, чтобы написать неудачный тестовый пример, прежде чем писать тестируемый код, и завершить разработку после успешного выполнения теста.
Для интеграционного тестирования и выше (тестирование системы) вам нужно будет рассмотреть, среди прочего, как привести тестовую среду в некоторое известное состояние в дополнение к рассмотрению того, что тестировать.
