как протестировать или описать бесконечные возможности?
Класс в качестве примера в псевдокоде:
class SumCalculator
method calculate(int1, int2) returns int
Что хороший путь состоит в том, чтобы протестировать это? Другими словами, как я должен описать поведение, в котором я нуждаюсь?
test1: canDetermineSumOfTwoIntegers
или
test2: returnsSumOfTwoIntegers
или
test3: knowsFivePlusThreeIsEight
Test1 и Test2 кажутся неопределенными, и он должен был бы протестировать определенное вычисление, таким образом, он действительно не описывает то, что тестируется. Все же test3 очень ограничен.
Что хороший путь состоит в том, чтобы протестировать такие классы?
5 ответов
Я бы протестировал граничные условия (max-int, min-int, zero, positive, negative) и некоторые типичные случаи:
test1: sumOfPosAndPos
test2: sumOfPosAndNeg
test3: sumOfPosAndZero
test4: sumOfNegAndZero
test5: sumOfMaxIntAndMinInt
и т.д.
Есть несколько философий. Рой Ошеров, автор книги Искусство модульного тестирования , кажется, предпочитает использовать явные значения и выбирать самое низкое (или простейшее) представление каждого класса эквивалентности .
Этот принцип не очень хорошо применим к вашему примеру, но действительно хорошо работает во многих других сценариях.
Если, например, класс требует ввода положительного целого числа, вы выбираете число 1 , потому что это простейшее представление всех положительных промежуточных чисел.
Лично я предпочитаю принцип, который я называю Ограниченным недетерминизмом . Дело в том, что мы позволяем какой-то фабрике обслуживать нас анонимными переменными для данного типа, потому что это заставляет нас устанавливать отношения непосредственно в тесте.
Я использую AutoFixture для этого (но вы также можете использовать что-нибудь еще), поэтому в этом случае я бы протестировал SumCalculator следующим образом:
var fixture = new Fixture();
var int1 = fixture.CreateAnonymous<int>();
var int2 = fixture.CreateAnonymous<int>();
var expectedResult = int1 + int2;
var sut = fixture.CreateAnonymous<SumCalculator>();
var result = sut.Calculate(int1, int2);
Assert.AreEqual(expectedResult, result);
В принципе, этот единственный тест обеспечивает спецификация для метода вычислений. Мы никогда не знаем, каковы значения int1 и int2 , и это очень уместно во всех тех случаях, когда это на самом деле не имеет значения.
если вы тестируете математическую функцию, я бы посоветовал вам протестировать ее по обратной функции, например: для функции, которая выполняет x = a + b , вы должны проверить, есть ли ax = -b и xb = a, это просто для иллюстрации, конечно, это не сработает в каждом случае.
Другой альтернативой здесь было бы использование параметризованного тестового примера для удаления дублирования в тестах. В основном таблица содержит все данные для тестов в форме кортежа ([term1, term2, sum]), затем тестовый набор выполняет итерацию по таблице при вызове параметризованного тестового набора для проверки строки в таблице:
Я бы также добавьте отрицательное (здесь переполнение) тестирование: что должен вернуть calculate (MAXINT, 1) ?
См. работу Дэвида Саффа о теоретических тестах; here (PDF) является примером. Это в основном способ сделать утверждение, что что-то (например, функция, обратная своей функции) истинно для всех значений в некотором множестве (включая множество всех возможных значений) - и выразить это утверждение в качестве теста. Вы можете сделать некоторые забавные вещи, запустив тест со случайно выбранными значениями (если набор слишком велик для исчерпывающего выполнения) и автоматически записав сбои в виде конкретных конкретных регрессионных тестов.