Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, Ziaw, Вы писали:

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

ВВ>Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме?

А как тесты у тебя это контролируют?

ВВ>Если, скажем, у меня задача читать ХМЛ, который приходит из внешнего источника — то это динамика. И если ты макросом сгенеришь красивый и как бы статически типизированный код для чтения этого ХМЛ-я — то это все равно будет динамика. Просто выглядящая как статика. И если вместо ХМЛ-я придет фигня, то все свалится в рантайме.

Кто мешает отловить экзепшен и сказать, что пришла фигня? Чем тут динамика поможет? Точно так же свалится в рантайме, если не делать проверок.

ВВ>Речь, наверное, не про "движения", а про меньшее количество тестов. Но тут мне тоже непонятно, насколько конкретно этих тестов будет меньше и как это вообще повлияет на разработку. Зато, например, мне понятно, что с тем же РОРом у меня уже есть готовый и работающий РЕПЛ. А вас пока только в планах. И я понимаю, что РЕПЛ-то как раз весьма заметно повлияет на мою эффективность.

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

Z>>Это что за задача с маленьким сервером и огромным клиентом?
ВВ>Это не задача, это один из вариантов решения.

Еще раз, что за задача, в которой сервер настолько прост, а гуи к нему настолько сложен, что такая разница в коде?

Z>>Это потому, что у тебя есть код и там и там, естественно ты его можешь и там и там править. У меня код только там, разъезжаться в таком случае просто нечему.

ВВ>Только "там" — это где? На сервере? Как у тебя так получается? Как можно писать приложения с богатым клиентским слоем, вроде того Гмейла, и не формировать HTML на джаваскрипте?

Бррр... Ты цитату не оттуда взял, это относилось к схеме бд и коду DAL.

ВВ>Да дело даже не в этом, пусть ДжаваСкрипт HTML вообще никак не генерит. Он что, с ним и не работает? Контрол задизеблить надо — сабмит форму или ее часть на сервер?

Я теряю полет мысли, честно.

Z>>Давай пример юнит теста и сценария в котором этот юнит тест нам будет полезен. Я не представляю о чем ты говоришь.

ВВ>А что непонятно-то Простые изолированные тесты, которые в первую очередь проверяют консистентность модели. Ну или корректность работы процедур, если они имеются. Скажем, один тест проверяет все процедуры для работы с конкретной сущностью — вставил, прочитал, сверил результаты, удалил.

Зачем проверять консистентность модели которая впрямую отображает БД и зачем нужны процедуры которые делают CRUD? При этом их еще и тестировать надо? В каком сценарии нам эти процедуры и тесты полезны будут?