Как писать юнит-тесты, если совсем не хочется

Это статически известно на этапе компиляции, можно всегда посмотреть в IDE или javadoc. Можно контролировать типы, например, выносом интерфейсов API в отдельный модуль с особыми правилами внесения изменений. Изменить тип можно только изменением декларации, никакое изменение тела метода тип не поменяет. Да, возможны редкие случаи, когда изменение типа метода не сломает весь остальной код, но это вполне нормально. В динамическом языке изменение тела одного метода может повлиять на результат других (которые делегируют к этому). Если делегация условная, другой метод может после такого изменения неожиданно возвращать разные типы в разных ситуациях. Я не понимаю, как можно уверенно рефакторить проект на динамическом языке, не обложившись тестами на типы аргументов и результатов методов.

p.fooo; // ESLint тут бесполезен

Может стоит решать эту проблему, а не писать рядом "своими словами"?

Эта проблема как раз и решается.

Было бы оно точное, его можно было бы скомпилировать, выкинув весь остальной код.

А оно и компилируется. Это обычный DSL.

Он работает так же, как в остальном програмном коде. Что ещё от него можно ожидать? Ну а что в некоторых языках нет перегрузки операторов и сравнение всегда по ссылке, так о том и речь, что некоторые языки имеют кривой дизайн, из-за чего приходится добавлять костыли типа to eq.

Это совершенно не этот случай, to eq тут написан именно для того чтобы выражение было читабельным, а не убогим дискретным ассертом без контекста и правильной ошибки.

Все эти красоты не имеют смысла при использовании отладчика, а не отладке через repl.

А ну теперь все понятно. Это еще один аспект TDD/BDD который сударь не вкурил. Тесты используются не только для валидации, а так-же как часть процесса разработки и отладки.

Нет. Одна строчка кода и 5 записанных в одну строку — не одно и то же.

Если 5 строчек дают контекст и читабельность — это лучше чем одна ниндзя-строка которая делает все на свете.

Читаемость и поддерживаемость одной строчки выше, чем пяти.

Крайне спорное утверждение.

Что легче читать и поддерживать?

message = "foo"  

if (type == "dar" ) {  
    message = "bar"  
} elsif (is_some_other_condition) {  
    message = "har"  
}  

или

error = (type == "dar" ? "bar : (is_some_other_condition ? "har" : "foo"))

Исходные коды — не картинная галерея. Это сугубо утилитарная вещь. А вы не из тех, кто выстраивает из исходников ascii-картинки?

Да, а еще я код форматирую. Каюсь, виновен — жутко не утилитарно.

и предположить что подобные ошибки в тестах были допущены не намеренно

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

системный подход в ловле таких проблем

Про это последний абзац статьи как раз :)

Большинство упомянутых в статье способов, к сожалению, легко находятся хорошим статическим анализатором

Если же каждый кусок кода покрыт отдельным тестом — а то и не одним — у вас будет более гранулярная картина, где именно и что сломалось (=опять сэкономленное время).

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

auto data1 = GetData1()
auto data2 = GetData2()
auto data3 = GetData3()
auto result = Calculate(data1, data2, data3)
assert(result[1][1]==10)

auto data1 = GetData1()
auto data2 = GetData2()
auto data3 = GetData3()
auto result = Calculate(data1, data2, data3)
assert(result[1][2]==15)

...(тонна тестов)...

позволяет точнее понимать эффект, который конкретное изменение кода привносит в кодовую базу — и насколько много изменений оно за собой потянет

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

Это позволяет планировать свое время

Тут важнее понимать что именно сломалось и как это чинить, а не сколько тестов упало.

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

Ну да, копипаста на 90% одинаковых тестов — это не простыня :-)