Поскольку он был публичный - позволю себе его процитировать:
"Ну типа того. Насчет УМЛ для ООП - все ок. А как быть с УМЛ для реляционных баз данных? Вот там тот самый избыточный код действительно даст катастрофическое падения перформанса, ибо оптимизация запросов - сложно формализуемый (неформализуемый) процесс. Ну, например расширения базового документа: добавление тагов, аттрибутов к нему в виде таблиц... Я так вообще использую фиребирд и ВСЯ логика сидит в БД. Это страшный сон. Зато очень эффективно. Кстати, я вообще интересуюсь твоим опытом, ибо сейчас у меня создана довольно мощная библиотека, почти что фреймворк и практически все новые сущности в ней создаются по шаблонам, меня реально задолбало каждый раз писать одно и то же (почти одно и то же), например для создания нового типа документа на основе базового класса. Намного быстрее было бы это рисовать. Ну а в идеале я уже писал - рисуешь модель - на выходе готовый продукт, остается добавить имплементацию. А если система еще и сама учится... Должно наступить такое время, когда самый тупой манагер диктует роботу, чего он желает и через пару минут получает готовую апликуху, функционал которой только наглядно подтверждает тупость того самого манагера. И для того, чтобы манагер понял, что занимается не своим делом уйдет не пол-года а те самые пары минут"
"На самом деле тест для моего примера сводится к следующему: - проверить, что сумма сохранилась в соответствующих таблицах - проверить, что создана запись в протоколе изменений. Но! Конечный продукт (упрощенно) - сумма должна попасть в отчеты. А этот факт зависит от множества параметров конфигурации и от данных самого документа. В результате сценарий теста будет по сложности сопоставим как минимум со сложностью настройки самой системы и где тот тест, что проверить тестовый сценарий на предмет логических ошибок?.. Я конечно понимаю, что формализовать, довести до элементарных тест-кейсов каждое действие возможно (это вообще можно встроить в систему) и в результате система сможет тестировать себя сама, но не могу себе представить реализацию всего этого, особенно в условиях меняющейся цели (например, когда изначальное задание устаревает и пояляются новые цели, а старые соответственно больше неактуальны и старые сценарии тестов неправильны или не нужны)."
Ну что сказать? Я ТАК И ДЕЛАЮ. Рисую, а не программирую.
"меня реально задолбало каждый раз писать одно и то же (почти одно и то же), например для создания нового типа документа на основе базового класса. Намного быстрее было бы это рисовать. Ну а в идеале я уже писал - рисуешь модель - на выходе готовый продукт, остается добавить имплементацию." - вот РОВНО так и делаю - РИСУЮ и ДОБАВЛЯЮ ИМПЛЕМЕНТАЦИЮ.
"Я конечно понимаю, что формализовать, довести до элементарных тест-кейсов каждое действие возможно (это вообще можно встроить в систему) и в результате система сможет тестировать себя сама" - у нас ИМЕННО так и устроено. Тесты встроены в систему. В отладочную версию.
И ещё одно мнение:
"Да, вопросы конечно правильные. Я тоже не раз задавался вопросами относительно правильного тестирования БДшных приложений. Там проблемы даже с тестовыми данными возможны - они сложные и сильно вариативные. И придумать как протестить, например, применение компенсаций и скидок с оборота при обслуживаниям по картам - не такая уж тривиальная задача. Но, думаю, если бы генерилось это дело с модели, всю картину происходящего было бы проще "обозреть"."
Не буду комментировать. Оставлю его открытым.
"Ну типа того. Насчет УМЛ для ООП - все ок. А как быть с УМЛ для реляционных баз данных? Вот там тот самый избыточный код действительно даст катастрофическое падения перформанса, ибо оптимизация запросов - сложно формализуемый (неформализуемый) процесс. Ну, например расширения базового документа: добавление тагов, аттрибутов к нему в виде таблиц... Я так вообще использую фиребирд и ВСЯ логика сидит в БД. Это страшный сон. Зато очень эффективно. Кстати, я вообще интересуюсь твоим опытом, ибо сейчас у меня создана довольно мощная библиотека, почти что фреймворк и практически все новые сущности в ней создаются по шаблонам, меня реально задолбало каждый раз писать одно и то же (почти одно и то же), например для создания нового типа документа на основе базового класса. Намного быстрее было бы это рисовать. Ну а в идеале я уже писал - рисуешь модель - на выходе готовый продукт, остается добавить имплементацию. А если система еще и сама учится... Должно наступить такое время, когда самый тупой манагер диктует роботу, чего он желает и через пару минут получает готовую апликуху, функционал которой только наглядно подтверждает тупость того самого манагера. И для того, чтобы манагер понял, что занимается не своим делом уйдет не пол-года а те самые пары минут"
"На самом деле тест для моего примера сводится к следующему: - проверить, что сумма сохранилась в соответствующих таблицах - проверить, что создана запись в протоколе изменений. Но! Конечный продукт (упрощенно) - сумма должна попасть в отчеты. А этот факт зависит от множества параметров конфигурации и от данных самого документа. В результате сценарий теста будет по сложности сопоставим как минимум со сложностью настройки самой системы и где тот тест, что проверить тестовый сценарий на предмет логических ошибок?.. Я конечно понимаю, что формализовать, довести до элементарных тест-кейсов каждое действие возможно (это вообще можно встроить в систему) и в результате система сможет тестировать себя сама, но не могу себе представить реализацию всего этого, особенно в условиях меняющейся цели (например, когда изначальное задание устаревает и пояляются новые цели, а старые соответственно больше неактуальны и старые сценарии тестов неправильны или не нужны)."
Ну что сказать? Я ТАК И ДЕЛАЮ. Рисую, а не программирую.
"меня реально задолбало каждый раз писать одно и то же (почти одно и то же), например для создания нового типа документа на основе базового класса. Намного быстрее было бы это рисовать. Ну а в идеале я уже писал - рисуешь модель - на выходе готовый продукт, остается добавить имплементацию." - вот РОВНО так и делаю - РИСУЮ и ДОБАВЛЯЮ ИМПЛЕМЕНТАЦИЮ.
"Я конечно понимаю, что формализовать, довести до элементарных тест-кейсов каждое действие возможно (это вообще можно встроить в систему) и в результате система сможет тестировать себя сама" - у нас ИМЕННО так и устроено. Тесты встроены в систему. В отладочную версию.
И ещё одно мнение:
"Да, вопросы конечно правильные. Я тоже не раз задавался вопросами относительно правильного тестирования БДшных приложений. Там проблемы даже с тестовыми данными возможны - они сложные и сильно вариативные. И придумать как протестить, например, применение компенсаций и скидок с оборота при обслуживаниям по картам - не такая уж тривиальная задача. Но, думаю, если бы генерилось это дело с модели, всю картину происходящего было бы проще "обозреть"."
Не буду комментировать. Оставлю его открытым.
шаблоны для генерации OR-мапинга или ONsql или любого другого, - самое милое дело. Нас вот завернули с новым хранилищем, а мы ж этот там уже как раз почти сделали.
ОтветитьУдалить