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

Общественный консенсус - тесты нужны.

Тесты показывают, что код вообще хоть как-то работает. Ты проверяешь, а кто-то не проверяет.
Хорошее тестовое покрытие позволяет уверенно рефакторить код. Без тестов ты всегда боишься, что что-то забыл и теперь приложение с багом. Эта боязнь сильно мешает рефакторингу. А без рефакторинга качество кодовой базы будет падать.
Юнит-тесты являются дополнительной документацией к тому, как использовать твой код.
Тесты могут являться первым пользователем какого-либо API. Это может позволить понять, насколько это API адекватное.
Test-Driven Development тоже любопытная штука (разработка кода в цикле «тесты, код, рефакторинг»).

Конечно у тестов есть минусы:

Написание тестов занимает, собственно, время. А время - деньги.
При изменении кода может потребоваться изменение тестов. Т.е. тесты усложняют поддержку кода в будущем (но и одновременно упрощают за счёт факторов, перечисленных выше).
Многие категории кода тестировать сложно, а некоторые - едва ли возможно. Например как написать тесты для драйвера к какому-нибудь устройству? Наверное нужно спроектировать и произвести специальное тестовое устройство, которым можно будет управлять и моделировать разные ситуации, для тестирования драйвера. Это очень непростая задача. К примеру в линуксе нет никаких тестов для драйверов, разработчики полагаются только на ручное тестирование.

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

Поэтому при написании тестов нужно придерживаться определённого баланса. Какого именно - никто не скажет, тут уже всё на ощущениях и опыте.

Общественный консенсус - тесты нужны.

Тесты показывают, что код вообще хоть как-то работает. Ты проверяешь, а кто-то не проверяет.
Хорошее тестовое покрытие позволяет уверенно рефакторить код. Без тестов ты всегда боишься, что что-то забыл и теперь приложение с багом. Эта боязнь сильно мешает рефакторингу. А без рефакторинга качество кодовой базы будет падать.
Юнит-тесты являются дополнительной документацией к тому, как использовать твой код.
Тесты могут являться первым пользователем какого-либо API. Это может позволить понять, насколько это API адекватное.
Test-Driven Development тоже любопытная штука (разработка кода в цикле «тесты, код, рефакторинг»).

Конечно у тестов есть минусы:

Написание тестов занимает, собственно, время. А время - деньги.
При изменении кода может потребоваться изменение тестов. Т.е. тесты усложняют поддержку кода в будущем (но и одновременно упрощают за счёт факторов, перечисленных выше).
Многие категории кода тестировать сложно, а некоторые - едва ли возможно. Например как написать тесты для драйвера к какому-нибудь устройству? Наверное нужно спроектировать и произвести специальное тестовое устройство, которым можно будет управлять и моделировать разные ситуации, для тестирования драйвера. Это очень непростая задача.

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

Поэтому при написании тестов нужно придерживаться определённого баланса. Какого именно - никто не скажет, тут уже всё на ощущениях и опыте.

Общественный консенсус - тесты нужны.

Тесты показывают, что код вообще хоть как-то работает. Ты проверяешь, а кто-то не проверяет.
Хорошее тестовое покрытие позволяет уверенно рефакторить код. Без тестов ты всегда боишься, что что-то забыл и теперь приложение с багом. Эта боязнь сильно мешает рефакторингу. А без рефакторинга качество кодовой базы будет падать.
Юнит-тесты являются дополнительной документацией к тому, как использовать твой код.
Тесты могут являться первым пользователем какого-либо API. Это может позволить понять, насколько это API адекватное.
Test-Driven Development тоже любопытная штука (разработка кода в цикле «тесты, код, рефакторинг»).

Конечно у тестов есть минусы:

Написание тестов занимает, собственно, время. А время - деньги.
При изменении кода может потребоваться изменение тестов. Т.е. тесты усложняют поддержку кода в будущем (но и одновременно упрощают за счёт факторов, перечисленных выше).
Многие категории кода тестировать сложно, а некоторые - едва ли возможно. Например как написать тесты для драйвера к какому-нибудь устройству? Наверное нужно спроектировать специальное тестовое устройство, которым можно будет управлять и моделировать разные ситуации, для тестирования драйвера. Это очень непростая задача.

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

Поэтому при написании тестов нужно придерживаться определённого баланса. Какого именно - никто не скажет, тут уже всё на ощущениях и опыте.