Бггг. it depends :)

Однозначно оправдывают при групповой разработке.

Но я считаю, что да.
Не все со мной согласны в этом чате :)))
И вообще в мире разработки...
Но все "адвокаты" тдд убеждены, что на длинных дистанциях - это спасение :)

И следует помнить, что  я всегда работаю в команде: я + я через неделю/месяц/год :)

По мне TDD это один из способ разбиения сложных и больших задач на решаемые подзадачи

Я предпочитаю вместо тестов делать Assert'ы повсюду, плюс делать эмулятор нагрузки (действий пользователей, работы приборов) - это помогает и протестировать работу каждой фичи по отдельности, и рабочий цикл (рутинные дейтвия), и предельные нагрузки (имитация сотен и тысяч пользователей или приборов).

Просто у меня большая система из множества модулей. Каждый модуль сам по себе может быть исправен, но вместе они дают разные квантовые эффекты.

Пока гуглил FPCUnit встречал информацию по Assert, спасибо!

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

Поделитесь опытом по отделению представления от модели.

Вот конкретный пример:
Есть два юнита=модели (классы с наследниками).
1. u_systemmagnetic

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_systemmagnetic.pas#L1

2. u_noload

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_noload.pas#L1

Есть юнит представление u_main

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L1

Есть контроллер, в виде класса-потока TMainThread в u_main.

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L42

Не могу понять, является это полным разделением модель-представление-контроллер или нет.
С одной стороны, u_systemmagnetic и u_noload полностью независимы, не содержат в implementation uses с u_main и могут быть подвергнуты ЮнитТестированию.
С другой стороны, контроллер находиться в одном юните с представлением и представление содержит в interface uses ссылки на u_systemmagnetic и u_noload.
А если контроллера вынести в отдельный юнит (u_main в uses будет содержать некий u_thread, а  u_thread в uses будет содержать u_systemmagnetic и u_noload), то как ему передать данные из представления, ведь в новом юните ему будут не видны классы представления (и опять возникнет вопрос который возник ранее-где освободить классы данных переданные в контролер из представления)?

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L139

А этап автоматизированного тестирования, как отдельный, можно (НУЖНО!) встраивать в процесс сборки

А это ты ссылки кодом сделал?

А юнит-тесты разве на этапе компиляции работают?

Имеете ввиду ссылки на ГитХаб? Или в самих юнитах?

Я имею в виду в сообщении. Там даны ссылки, но они не кликабельные. "Никто не будет" копировать из и вставлять в браузер.

А ассерты? ;)

Исправил, что то пошло нет так после изменения шрифта...

Если ты про "автоматически запускать при сборке", но я про юнит тесты. Юнит-тесты - это отдельное приложение, которое можно запускать, и которое говорит "всё хорошо" или "сломалось столько-то тестов".. Ну и там статистика по тестам (чтобы графики всякие строить и смотреть потом динамику изменений)

C ассертами все просто и понятно, они ловят аномалии и некорректные параметры. Могут через месяц успешной работы поймать какую-нибудь аномалию железа или ОС. А тесты так могут?

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