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

Какая разница, где?

Экспериментировать лучше вне проекта. Чтобы случайно что-нибудь не испортить и не забыть потом отменить. VCS конечно помогает, но всё равно лучше на игрушечном проекте обкатать библиотеку или алгоритм.

При каком планировании? Речь не о том, что я в план не уложусь. Речь о том, что эксперименты должны быть быстрыми, чтобы можно было за оставшиеся до обеда полчаса накидать десяток вариантов. Пока находишься в потоке. Не отвлекаясь.

Для этого тесты не подходят.

Я пишу на Scala.

А 99% остальных людей пишут на Java, PHP, C#. И им нужна стратегия, при которой будет получаться продукт, удовлетворяющий всем необходимым требованиям. Кроме того Scala это не что-то волшебное. Она может проверять больше, чем Java, естественно это тестировать не надо. Компилятор обычно работает без багов. Но необходимость тестов это не отменяет.

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

В ситуации, где ошибку вообще допустить нельзя — однохренственно.

Таких ситуаций не бывает. Даже в космических челноках с космонавтами ошибки допускают. Даже в системах жизнеобеспечения есть баги. При том, что даже в захудалом интернет-магазине ошибки допускать «нельзя». Можно говорить о том, какие требования к качеству предъявляются. И что можно сделать, чтобы повысить качество (уменьшить число багов). Тесты это одна из методик повышения качества. Не единственная и не серебряная пуля.

Если у меня прямо в коде написано «sum [] = 0», то на кой хрен мне ещё писать «assert (sum [] = 0)»? У меня что, это когда-нибудь поменяется?

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

Тесты, разумеется, нужны. Но тесты нужны на то, что имеет смысл тестировать. И после написания первой версии кода — когда мы уже точно знаем, как этот код должен работать.

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

Какая разница, где?

Экспериментировать лучше вне проекта. Чтобы случайно что-нибудь не испортить и не забыть потом отменить. VCS конечно помогает, но всё равно лучше на игрушечном проекте обкатать библиотеку или алгоритм.

При каком планировании? Речь не о том, что я в план не уложусь. Речь о том, что эксперименты должны быть быстрыми, чтобы можно было за оставшиеся до обеда полчаса накидать десяток вариантов. Пока находишься в потоке. Не отвлекаясь.

Для этого тесты не подходят.

Я пишу на Scala.

А 99% остальных людей пишут на Java, PHP, C#. И им нужна стратегия, при которой будет получаться продукт, удовлетворяющий всем необходимым требованиям.

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

В ситуации, где ошибку вообще допустить нельзя — однохренственно.

Таких ситуаций не бывает. Даже в космических челноках с космонавтами ошибки допускают. Даже в системах жизнеобеспечения есть баги. При том, что даже в захудалом интернет-магазине ошибки допускать «нельзя». Можно говорить о том, какие требования к качеству предъявляются. И что можно сделать, чтобы повысить качество (уменьшить число багов). Тесты это одна из методик повышения качества. Не единственная и не серебряная пуля.

Если у меня прямо в коде написано «sum [] = 0», то на кой хрен мне ещё писать «assert (sum [] = 0)»? У меня что, это когда-нибудь поменяется?

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

Тесты, разумеется, нужны. Но тесты нужны на то, что имеет смысл тестировать. И после написания первой версии кода — когда мы уже точно знаем, как этот код должен работать.

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