Какие тестовые сценарии реализовать для проверки методов push и pop стека?

Что проверяют

Умеете ли вы превращать контракт структуры данных в набор проверок, а не ограничиваетесь «положил и достал». Интервьюер смотрит на граничные случаи и на то, тестируете ли вы поведение через публичный интерфейс. Часто следом просят написать пару тестов на pytest.

Как отвечать

Сначала уточните контракт: что делает pop на пустом стеке, есть ли ограничение ёмкости, есть ли peek и len. От ответа зависят ожидаемые результаты. Дальше сценарии:

• push в пустой стек: len становится 1, peek() возвращает элемент;
• порядок LIFO: после push(1), push(2), push(3) три вызова pop() дают 3, 2, 1;
• pop возвращает и удаляет: значение совпадает с последним добавленным, размер уменьшился на единицу, следующий pop отдаёт предыдущий элемент;
• pop на пустом стеке: ожидаемое исключение, у встроенного list это IndexError. Проверяется через with pytest.raises(IndexError):;
• опустошение и повторное использование: вытащили всё, стек пуст, после нового push снова работает корректно;
• чередование: push, pop, push, push, pop с проверкой состояния после каждого шага;
• разные значения: None, изменяемые объекты, дубликаты. None особенно коварен, если реализация сигналит о пустоте возвратом None;
• ограниченная ёмкость, если она есть: push в полный стек даёт оговоренное исключение, содержимое не меняется.

Покажите технику: фикстура с новым стеком на каждый тест, @pytest.mark.parametrize для наборов данных. Хороший плюс это свойство на Hypothesis: для любого стека push(x) и следом pop() возвращают x и не меняют остальное содержимое.

Где спотыкаются

Проверяют внутренний список stack.items вместо pop, peek и len. Такие тесты ломаются при любом рефакторинге реализации, хотя поведение не изменилось.

Для переполнения предлагают OverflowError. Это исключение для арифметики, для полной коллекции лучше своё, например StackFullError.

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