Какие структуры данных используешь в тестах?

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

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

Как отвечать

Отвечайте от задач, которые решаете, и называйте свой стек. Типичный набор для Java или Python:

• списки и массивы: наборы входных данных для параметризованных тестов, @MethodSource со Stream<Arguments> в JUnit 5 или список кортежей в @pytest.mark.parametrize;
• словари и Map: заголовки и query-параметры запросов, ожидаемые значения полей, контекст сценария для передачи данных между шагами в Cucumber;
• множества: сравнение коллекций без учёта порядка и проверка уникальности, например что в выдаче нет повторяющихся id;
• модели данных: record или POJO с Lombok в Java, dataclass или модели Pydantic в Python. Тело запроса и ответа описано типом, а не картой строк, и ошибки ловятся раньше;
• билдеры и фабрики: паттерн Test Data Builder, чтобы собрать валидный объект и поменять в тесте только одно поле;
• деревья JSON: JsonNode в Jackson или JSONPath для проверки вложенных ответов API.

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

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

Перечисляют стек, очередь и дерево без единого примера. Интервьюер слышит пересказ учебника, а не опыт.

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

Держат общий изменяемый статический Map для всех тестов. При параллельном запуске тесты затирают данные друг друга, у каждого теста должно быть своё состояние.