Методы проектирования тестов на основе спецификаций для улучшения модульных тестов

Как вы можете видеть, в своих тестах я использую атрибут NUnit TestCase . Как только метод будет выполнен, будет выполнено семь тестов на основе значений, предоставленных через атрибуты. Первое значение представляет ageInput; вторая — ожидаемая цена.

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

Как видно из таблицы, существует семь разделов эквивалентности: четыре действительных и три неверных. Я покрываю их все значениями из последней строки таблицы.

Ошибки разделения эквивалентности, чтобы помнить

Хотя этот метод относительно прост, люди допускают некоторые распространенные ошибки при его применении.

1. Различные подмножества не могут иметь общего члена. Если значение присутствует в двух разделах, вы не можете определить, как оно должно вести себя в разных случаях.

2. Ни одно из подмножеств не может быть пустым. Если вы не можете выбрать тестовое значение из набора, оно не пригодно для тестирования.

Тесты на основе спецификаций: на основе анализа граничных значений

Так что же такое анализ граничных значений?

Это метод проектирования теста черного ящика, в котором контрольные примеры разрабатываются на основе граничных значений. Но тогда, каковы граничные значения?

Граничными значениями являются входные значения или выходные значения, которые находятся на границе раздела эквивалентности или наименьшего возрастающего расстояния по обе стороны от края, такого как, например, минимальное или максимальное значение диапазона.

Это техника для уточнения разделения эквивалентности. Анализ граничных значений является следующей частью разделения эквивалентности . В нем тестовые случаи отбираются по краям классов эквивалентности. Критерий покрытия состоит в том, что каждое граничное значение, как действительное, так и недействительное, должно быть представлено как минимум в одном тесте.

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

Все ли классы эквивалентности имеют граничные значения?

Нет, определенно нет. Анализ граничных значений применяется только тогда, когда упорядочены члены класса эквивалентности.

Сколько граничных значений существует?

Существует два представления о том, сколько граничных значений должно существовать. Большинство людей считают, что только два значения должны быть получены из каждого края раздела эквивалентности. Таким образом, в следующем условии 0 <Age> 6 для первого ребра граничные значения будут равны 0, 1, а для второго предела 5, 6 .

В своей книге « Тестирование программной системы и обеспечение качества» Борис Бейзер объясняет другой вариант: три значения на границу, где каждое ребро считается одним из тестовых значений в дополнение к каждому из его соседей. Для предыдущего условия 0 <Age> 6, для 0 тестовые значения будут -1, 0 и 1. Для 6 тестовыми значениями будут сами 6, 5 и 7.

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

Тесты с использованием анализа граничных значений

Используя методику проектирования тестов на основе анализа граничных значений, я создал в общей сложности 20 тестов для TransportSubscriptionCardPriceCalculator до процесса написания реального кода, только на основе требований спецификации.

private const string GreaterThanZeroExpectionMessage = "The age should be greater than zero.";
private const string SmallerThan123ExpectionMessage = "The age should be smaller than 123.";
private const string ShouldBeIntegerExpectionMessage = "The age input should be an integer value between 0 - 122.";

[TestCase("-1", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = GreaterThanZeroExpectionMessage)]
[TestCase("0", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = GreaterThanZeroExpectionMessage)]
[TestCase("1", 0)]
[TestCase("4", 0)]
[TestCase("5", 0)]
[TestCase("6", 20)]
[TestCase("17", 20)]
[TestCase("18", 20)]
[TestCase("19", 40)]
[TestCase("64", 40)]
[TestCase("65", 5)]
[TestCase("66", 5)]
[TestCase("121", 5)]
[TestCase("122", 5)]
[TestCase("123", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = SmallerThan123ExpectionMessage)]
[TestCase("a", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = ShouldBeIntegerExpectionMessage)]
[TestCase("", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = ShouldBeIntegerExpectionMessage)]
[TestCase(null, 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = ShouldBeIntegerExpectionMessage)]
[TestCase("2147483648", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = ShouldBeIntegerExpectionMessage)]
[TestCase("–2147483649", 0, ExpectedException = typeof(ArgumentException), ExpectedMessage = ShouldBeIntegerExpectionMessage)]
public void ValidateCalculateSubscriptionPrice1(string ageInput, decimal expectedPrice)
{
    decimal actualPrice = TransportSubscriptionCardPriceCalculator.CalculateSubscriptionPrice(ageInput);

    Assert.AreEqual(expectedPrice, actualPrice);
}