История изменений

Наоборот, мы в тесты включаем ФС. Настоящую, реальную, ту что будет крутится на продакшене (в идеале, я держу dev максимально похожим на продакшн).

в интеграционные? в юнит? во все подряд как получится? задумайся над этим.

Ты сейчас написал что интеграционные тесты не нужны что-ли?

вот туда же, читать не умеют, а лезут.

Я не говорил что одно другое заменяет.

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

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

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

Покрытие же всех возможных путей выполнения... Ты пошутил?

обычно кавередж у нас на проектах пляшет в районе 80% по строкам и 60% по условиям в модульных/интеграционных тестах примерно 80/20. учитывая обработчики ошибок, которые автотестами ловить больно - ну не все, но 90-95% путей выполнения у нас покрыты, в основном модульными тестами, которые, о чем я изначально и писал, позволяют не плодить интеграционные тесты в безумных количествах.

давай не будем превращать дискуссию в задротство «кто больше умных книжек по тестированию прочитал и знаем много умных терминов»

заметь, я даже прошел мимо Goury, который мешает в кучу виды и уровни тестирования, противопоставляя функциональное тестирование юнит-тестированию

Наоборот, мы в тесты включаем ФС. Настоящую, реальную, ту что будет крутится на продакшене (в идеале, я держу dev максимально похожим на продакшн).

в интеграционные? в юнит? во все подряд как получится? задумайся над этим.

Ты сейчас написал что интеграционные тесты не нужны что-ли?

вот туда же, читать не умеют, а лезут.

Я не говорил что одно другое заменяет.

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

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

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

Покрытие же всех возможных путей выполнения... Ты пошутил?

обычно кавередж у нас на проектах пляшет в районе 80% по строкам и 60% по условиям в модульных/интеграционных тестах примерно 80/20. учитывая обработчики ошибок, которые автотестами ловить больно - ну не все, но 90-95% путей выполнения у нас покрыты, в основном модульными тестами, которые, о чем я изначально и писал, позволяют не плодить интеграционные тесты в безумных количествах.