Я уже которую страницу пытаюсь объяснить Дяде Вове, что так все делают, это универсальный подход.

И эти люди рассказывают мне про качество ПО facepalm.jpg

LSD, тебе не приходило в голову, что юнит тесты как воздух нужны, когда в коде присутствует много динамики(динамическая типизация, динамическое связывание и т.п.), когда код должен запускаться на окружении, отличном от окружения, где он реализуется. Такие случаи, в общем, по большей части, просто не про делфю.

В классическом делфийском приложении, разве что SQLчики динамические. 

Zloxa, если Delphi не "тянет" даже unit тесты, то это очень плохо. И динамика тут не причём. И вообще 
 тоже не всегда хорошо.


А для чего тогда делфи?

Мордочки к базам же.
Давно ведь место его уже определено 
Ну или какие нить мелкие миленькие поделочки.

Добавлено @ 17:11

Есть идеи как бахнуть их туда статикой?

В прочем - есть. Заворачиваем в пакетик, генерим враппер и вуаля   

Это сообщение отредактировал(а) Zloxa - 23.4.2013, 17:16

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

Вот и определились, для этого вам не нужны плюсы, ява и прочие глупости. Забудьте  

Добавлено через 1 минуту и 2 секунды
Любое вменяемое ПО должно быть покрыто тестами, если конечно это не разовая задача

Это сообщение отредактировал(а) Felix12321 - 23.4.2013, 17:25

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

Кто-то запрещает в дизайнере установить свойство Active в true?

Тут без тестов уже никуда.
Ну кэшно для "Мордочки к базам" это может и не относиться.

update, insert, delete?

И что оно даёт?
Проверку всех запросов при компиляции?

Пакетик, врап, автоматический реврап при сборке.
Изменилась спецификация вызова интерфейсного пакета - лови красные выделения в коде.

С курсорами хуже.

Вывод неправильный. Юнит-тестирование практически бесполезно, если сложно сформулировать правильность работы метода. Я выше привел пример с картинкой, Дядя Вова, как обычно свел все к GUI, хотя я могу и выполнив обработку просто послать ее в файл. Как ты будешь такой метод проверять? Попиксельно сравнивать с тестовым образцом? Ну и само наличие\отсутствие инструментов часто означает лишь то, что в одном случае проблема критична и ее надо решать, а в другом, он не имеет места быть, или малоактуальна.



Ты забыл добавить "до нескольких сотен и тысяч метров в инсталле".



А чем твои знания ПО, явно ограничивающиеся жабой и исключительно серверами лучше моих? И почему для меня должны быть важны критерии, которые важны для тебя? В конце концов если жаба такая хорошая и правильная, то почему на десктопе она сфейлилась, а построенный на тех же идеях шарп пошел?

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

Неужели тебе не доводилось никогда использвоать позднее связываение с COM объектами? Вот где действительно нужны юнит тесты, авто тесты. Как часто таким приходится заниматься? Мне лично - крайне редко.

Это сообщение отредактировал(а) Zloxa - 23.4.2013, 18:00