Написание тестов для метода ценообразования

Question

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

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

Например:

Продукт A имеет ценовую матрицу ниже (количество внизу и размер вдоль верха)

----------------------------
|     | xs |  s |  m |  l  | 
----------------------------
|  250| 10 | 20 | 50 | 100 | 
----------------------------
|  500| 20 | 40 | 60 | 110 | 
----------------------------
| 1000| 15 | 25 | 55 | 105 | 
----------------------------
| 1500| 12 | 22 | 52 | 102 | 
----------------------------

Теперь скажите, что я писал тесты для метода класса

Pricer.GetPrice(Product p, string size, int quantity)

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

Если цены получены из хранилища данных и, следовательно, могут измениться, как вы делаете свои тесты правильными или это просто раздражает продукт?

Также есть ли у кого-нибудь хорошие ссылкичитайте по поводу написания тестов / TDD.Может быть, пройти через CRUD / Repositories, так как это похоже на сценарий типа курицы и яйца.

Answer 1

Похоже, что в вашей логике ценообразования есть два элемента.

1. Структура данных матрицы цен, отображающая (размер, ограничение количества) пары цен.

2. Функция, которая принимает матрицу цен и экземпляр Product и возвращает цену.

Проверка матрицы цен не имеет смысла;числа являются произвольными.Если вы чувствуете, что вам нужно протестировать функцию, я бы передал ей разные поддельные, жестко закодированные тестовые матрицы с различными фиктивными продуктами и проверил, чтобы убедиться в том, что выбрана правильная цена.Наиболее релевантными крайними случаями, вероятно, являются случаи, когда вы запрашиваете цену для количества отсечения точно или по одному от одного.

Answer 2

Я думаю, что ваше тестирование должно быть конкретным, и вам нужно определить, что вы тестируете, прежде чем приступить к написанию теста.

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

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

Вы можете проверить это: размер X и количество Y должны дать цену Z. Вставьте значения для X и Y и убедитесь, что вы получите ожидаемое значение для Z.

Что еслинет значения для X или Y?Вы терпите неудачу?Вернуть 0?Эти вещи вы можете проверить.

Answer 3

Модульное тестирование - это тестирование наименьшей возможной единицы кода, поэтому в этом случае все, что вас волнует, - это то, что метод возвращает ожидаемую цену. Если метод получает данные о ценах извне, то он делает две вещи: получение данных о ценах и расчет цены. Вы обнаружили нарушение SRP .

Разделите его на два метода: один для получения данных о ценах , а другой для расчета цен (с использованием данных о ценах, переданных в качестве параметра).

Итак, ваш целевой метод теперь выглядит так:

GetPrice(Product p, string size, int quantity, sometype pricingData)

Теперь вы можете проверить расчет изолированно:

var pricingData = GetKnownPricingData(); // get a set of dummy pricing data
var result = Pricer.GetPrice(product, size, quantity, pricingData);

Затем вы можете проверить ожидаемый результат на основе известных данных о ценах.

Answer 4

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