Можно ли писать тесты без фреймворка

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

Понимаете ли вы, что даёт фреймворк помимо функции проверки утверждений. Ответ показывает, задумывались ли вы про запуск, отчётность и поддержку тестов, или для вас тест это просто скрипт, который что-то посчитал и напечатал.

Как отвечать

Да, можно, и иногда именно так и делают: разовая проверка гипотезы, скрипт для подготовки данных, проба незнакомого API. В некоторых экосистемах граница вообще размыта: в Go тесты пишут на стандартном пакете testing, таблицей случаев и подтестами, и сторонний фреймворк там скорее исключение.

Дальше назовите, что теряется без готового инструмента:

• обнаружение и запуск: кто-то должен найти тесты, выполнить их и вернуть код возврата, по которому упадёт сборка;
• изоляция: первый же непрошедший assert прерывает функцию, остальные проверки не выполняются, и падение прячет от вас соседние дефекты;
• подготовка и уборка: фикстуры, общие данные, гарантированный откат после теста;
• параметризация, повторный прогон нестабильных проверок, параллельное выполнение;
• машинно-читаемый отчёт, который система сборки покажет списком, а не строчкой в логе.

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

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

Опираются на голый assert в Python и не знают, что при запуске с оптимизацией такие проверки вырезаются на этапе компиляции, а тест становится вечно зелёным.

Печатают результат и на этом останавливаются. Скрипт, который пишет «всё прошло», но всегда завершается успешно, не остановит выкладку, поэтому первым делом нужен ненулевой код возврата.

Ставят вопрос ребром: фреймворк или ничего. На собеседовании ждут границу применимости, и ответ «для проверки на коленке хватит скрипта, для регресса нужен раннер» звучит сильнее лозунга.