Тестовые случаи стека

Question

Стек реализуется через связанный список .Какие тестовые случаи , когда он работает, а когда нет?

Answer 1

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

1. Можно поместить предмет в стек и вытолкнуть его.
2. Когда вы кладете несколько разных элементов в стек, повторное выталкивание возвращает их в обратном порядке.
3. Неинициализированный стек пуст.
4. Стек, в который помещен элемент, не пуст.
5. Стек, в котором элементы помещены и впоследствии удалены, пуст.
6. Попытка всплывающего окна при отсутствии элементов приводит к задокументированному типу сбоя, независимо от того, возвращает ли он значение NULL, выдает исключение или прерывает программу.

Подведем итог:

• Базовая функциональность.
• заказ недвижимости.
• Пустота инвариантная.
• Режим отказа.

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

Answer 2

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

Пример: ваш базовый стек должен иметь push() и pop(), поэтому:

• создать элемент A,
• толчок A в стеке,
• всплывающий элемент
• посмотреть, является ли это элементом А.

Особенно протестируйте крайние случаи: удаление последнего элемента, вставка элемента дважды, вставка недопустимых объектов, ссылки на сам стек, удаление объектов, находящихся в стеке.