Приходилось ли писать тесты на прошлых проектах и какой был coverage?

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

Цифра покрытия это приманка. Смотрят, понимаете ли вы, что покрытие считает исполненные строки, а не проверенное поведение, и умеете ли выбирать, что тестировать в первую очередь.

Как отвечать

Назовите честную цифру по своему проекту и сразу то, чем она подкреплена. Инструменты: pytest, покрытие через pytest-cov поверх coverage.py, параметризация вместо копий теста, monkeypatch и подмены для внешних вызовов, фиксация времени, перехват HTTP, отдельная база или контейнер для интеграционных.

Что сказать дальше:

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

Сильная реплика: полное покрытие вредно как цель, потому что дорисовываются тесты на тривиальный код. Честнее качество показывает мутационное тестирование, которое портит код и смотрит, заметят ли это тесты.

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

Называют красивое число и не могут сказать, что в знаменателе. Тест, который вызывает функцию и ничего не утверждает про результат, даёт ровно такие же цифры, что и осмысленный.

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

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