Здравствуйте, Ziaw, Вы писали:
ВВ>>Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме?
Z>А как тесты у тебя это контролируют?
Тесты создают несколько типичных случаев для рантайма. Если все эти варианты проходят, делается вывод, что код корректный. Это само собой не означает, что мы не забыли о чем-то, и код на самом деле не содержит баги. Ну так мир не идеален.
А как тесты вообще что-либо контролируют? Ты что ли тесты не писал?
ВВ>>Если, скажем, у меня задача читать ХМЛ, который приходит из внешнего источника — то это динамика. И если ты макросом сгенеришь красивый и как бы статически типизированный код для чтения этого ХМЛ-я — то это все равно будет динамика. Просто выглядящая как статика. И если вместо ХМЛ-я придет фигня, то все свалится в рантайме.
Z>Кто мешает отловить экзепшен и сказать, что пришла фигня? Чем тут динамика поможет? Точно так же свалится в рантайме, если не делать проверок.
Динамика ничем не поможет. Сам сценарий изначально — это динамика. Чтение ХМЛ через XmlReader — это динамика. Работа с базой — это динамика. Динамика — это просто данность. Тут другой вопрос — чем в данном случае поможет статика?
ВВ>>Речь, наверное, не про "движения", а про меньшее количество тестов. Но тут мне тоже непонятно, насколько конкретно этих тестов будет меньше и как это вообще повлияет на разработку. Зато, например, мне понятно, что с тем же РОРом у меня уже есть готовый и работающий РЕПЛ. А вас пока только в планах. И я понимаю, что РЕПЛ-то как раз весьма заметно повлияет на мою эффективность.
Z>Именно про движения, чтобы внести правки в код чрезмерно обложенный тестами надо исправить больше тестов.
Да ну, не так страшен черт. Что вы так боитесь этих тестов-то? Меняются готовые тесты вообще довольно редко. Чаще пишутся новые. Сделал фичу — парочку-другую тестов для нее. Это уже до автоматизма доходит. Времени всего ничего. Зато доходит чуть ли не до 100% coverage.
Z>>>Это что за задача с маленьким сервером и огромным клиентом?
ВВ>>Это не задача, это один из вариантов решения.
Z>Еще раз, что за задача, в которой сервер настолько прост, а гуи к нему настолько сложен, что такая разница в коде?
Причем тут ГУИ? Я говорю — вся логика пишется на клиенте. *Вся логика*. Кроме той, которую просто чисто физически нельзя писать на клиенте. Практически любое приложение можно так написать.
Z>>>Это потому, что у тебя есть код и там и там, естественно ты его можешь и там и там править. У меня код только там, разъезжаться в таком случае просто нечему.
ВВ>>Только "там" — это где? На сервере? Как у тебя так получается? Как можно писать приложения с богатым клиентским слоем, вроде того Гмейла, и не формировать HTML на джаваскрипте?
Z>Бррр... Ты цитату не оттуда взял, это относилось к схеме бд и коду DAL.
Тогда я уже не понимаю. У меня ДАЛ-а на клиенте тоже нет, откуда бы он там взялся.
Z>>>Давай пример юнит теста и сценария в котором этот юнит тест нам будет полезен. Я не представляю о чем ты говоришь.
ВВ>>А что непонятно-то
Простые изолированные тесты, которые в первую очередь проверяют консистентность модели. Ну или корректность работы процедур, если они имеются. Скажем, один тест проверяет все процедуры для работы с конкретной сущностью — вставил, прочитал, сверил результаты, удалил.
Z>Зачем проверять консистентность модели которая впрямую отображает БД и зачем нужны процедуры которые делают CRUD?
Чтобы убедиться в том, что нет рассинхрона.
Z>При этом их еще и тестировать надо? В каком сценарии нам эти процедуры и тесты полезны будут?
В основном regression testing. Собственно, один из основных смыслов юнит-тестов.