Судя по ответам, которые мы получили от посетителей конференций Joker, Heisenbug и JPoint, примерно в половине компаний есть требования по набиванию тестового покрытия (обычно 60-70% кода должно быть покрыто тестами).

Однако, при личном общении с разработчиками и тестировщиками мы постоянно слышим, что никаких требований нет и покрытие никак не контролируется.

Кто отвечает за тестовое покрытие? Должны его набивать разработчики или эта задача ложится на плечи тестеров? Будем благодарны, если ответите на 1 (один) вопрос. Если хочется поделиться болью и рассказать подробней, как у вас в проекте обстоят дела с тестовым покрытием, пишите в комментарии.

Комментарии (7)


  1. Dhwtj
    23.05.2025 10:26

    Если тест синих (чистых) функций, то тестовое покрытие вполне качественно сделает LLM. Неплохая штука для проверки что контракты не сломались. Особенно в rust, где всё уже в стандарте языка.

    Тесты красных функций я тупо не делаю.

    Особенно, если они зависят от БД или сети. Некоторые делают in memory implementation и тестят самый минимум, happy path


    1. Wilno
      23.05.2025 10:26

      A testcontainers? Не помогают?


      1. Dhwtj
        23.05.2025 10:26

        Что-то специфические для Java?

        Даже не знаю что это такое


      1. Gorthauer87
        23.05.2025 10:26

        Туда многое не очень то влезает, вот с Кафкой уже все будет не очень просто.


  1. YegorP
    23.05.2025 10:26

    95% покрытия юнит-тестами без требования набивать

    Как так вышло:

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

    • Во-вторых, это маленький проект в районе 40к LOC собственно кода и 40к LOC тестов. Я сам удивлён таким совпадением - только что посчитал. Около 2000 отдельных тестов. Исполняется за 3 минуты раннером гитхаба и за полторы минуты на моём обычном ноуте.

    • В-третьих - и это чуть ли не решающий момент - код нельзя запустить локально кроме как через юнит-тесты. Когда ты не можешь что-то просто запустить и "протыкать" сценарии руками, ты естественным образом придёшь к высокому покрытию. Почему нельзя запустить локально - это отдельный разговор и отдельная история. Технически-то можно этого добиться, но мы очень быстро распробовали кодинг полностью через тесты. Да, минусы в этом есть, но повторюсь, отдельный разговор.

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

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


  1. NeoNN
    23.05.2025 10:26

    Ложная дихотомия, это и MustHave и Bullshit. Так как даже 100% покрытие это не гарантия от багов, см. Pesticide Paradox


    1. DasMeister
      23.05.2025 10:26

      Задача автоматического тестирования никогда и не была в гарантии отсутствия багов. А в достижимости этой цели в принципе. В отличии от ситуации когда тестов вообще нет.