Изоляция — это не избавление от зависимостей. Это возможность изоляции модуля от остальных частей системы. Возможность инъекции зависимости и далее, подмена зависимостей стабами или моками. Да, в вашем случае следует изолировать путем инъекции стаба или мока персистенс-лэйера.
Покрытый подобными тестами код будет 100% изолирован и вы в любом случае сможете рефакторить отдельный кусок персистенс-лэйера или бизнесс-объекта в дальнейшем без страха поломать систему в целом. Я говорю именно об этом. Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
Вы хотите протестировать слой БД или слой бизнесс-объектов? Первое — да, никак. Но это опять же — проблема архитектуры. БД — это всего-лишь persistence layer для ваших бизнесс-объектов, которые и нужно тестировать ;-)
Говнокод в принципе не может научить писать хороший код. Чтобы писать хороший код — вы должны знать как его писать. Если вы знаете, что это говнокод, значит вы УЖЕ знаете как надо писать правильно. А вот если вы не знаете — тогда да, говнокод может чему-то научить, но отнюдь не «правильному» написанию кода.
Например? Чтобы чему-то научиться, нужно знать как НУЖНО делать, а не как НЕ НУЖНО. Если вы знаете как нужно, но видите перед собой говнокод, в котором сделано через одно место — вы не получаете новые знания, вы лишь понимаете, что тут сделано неправильно. Вот и все. Учиться чему-то можно только постоянно поднимая планку качества своего кода, а не понижая ее!
Ну и я думаю само собой разумеется, что глупо делать рефакторинг неизолированного модуля. Рефакторинг модуля, изоляция которого недоказана (не оттестирована) — тоже глупая затея, ибо вы играете в русскую рулетку с продакшен кодом. Т.е. безтестовый говнокод (99% случаев) не поддается рефакторингу — вот все что я хотел сказать. Качество кода тут не особо важно.
Я не говорю, что невозможно писать качественный код без юнит-тестов. Я лишь говорю, что юнит-тесты позволяют устранять огрехи в изоляции модулей еще на этапе тестирования или проектирования (для TDD). Вот и все. И да, если мы говорим о говнокоде — он не покрыт тестами. Покрытый тестами говнокод — это очень редкий случай. При чем здесь качество?
Нет, без юнит-тестов писать изолированный код в 100 раз сложнее, а говнокод — в 1000 раз легче.
Я лишь говорю о том, что если у вас на руках есть говнокод — он в 99% случаев будет без юнит-тестов ;-)
Говнокод в 99% обуславливает отсутствие юнит-тестов. В рабочей системе без юнит-тестов (и изоляции модулей как следствия) модульный рефакторинг невозможен в принципе!
Переписывание кусков кода возможно, но вы этим обрекаете себя на анальные муки в случайные моменты времени, когда из-за вашего свежего, «правильного» решения будут ломаться все новые и новые «неправильные» куски системы, абсолютно не связанные, на первый взгляд, с переписанным кодом.
Посему, копание в работающем говнокоде почти всегда требует от разработчика одного и только одного — писать новый говнокод, вставляя костыли и распорки для существующей системы.
И дело тут вовсе не во времени. Если бы времени было достаточно — вопрос о копании в говнокоде просто не стоял бы, но его почти всегда нет.
Я вот, если честно, не понимаю как вы можете говорить про «заменит неоптимальный код более верным»! Говнокод почти всегда подразумевает отсутствие тестов как класса. Это не просто заменить железную шестеренку на золотую в часах. В этом случае правильная, отлаженная шестеренка, вставленная в правильное место вместо неправильной может привести к неверной работы системы в целом в случайный момент времени. Потому что другая деталь в системе в случайный момент может попытаться дернуть вашу шестеренку, ожидая на выходе заложенное изначально неверное поведение.
Если есть запущенный проект с говнокодом, но без тестов — он в 99% случаев не поддается модульному рефакторину, ибо для рефакторинга нужна оттестированная изоляция модулей! Если же проект имеет юниты — проект в принципе уже не говнокодный.
Для вышеуказанной интеграции с социальными ресурсами (логин/анлогин, выбор пользователя) необходима работа со стороны самого сервиса. От сервиса будет необходимо выложить какой-то специальный xml в корень сайта, из которого firefox и будет брать информацию. Ни один сервис не станет делать лишнюю работу для интеграции какого-то плагина (а их может быть несколько) для определенного браузера, а вот для интеграции стандарта и работающего на нем браузера — станут.
Уважаете ветеранов? Вступите в фонд помощи ветеранам и помогайте им физически, а не поиском слов, способных в них вызвать раздражение в определенном контексте.
Если бы меня кто-то пырнул карандашом — меня бы меньше всего интересовало переименование карандаша в ручку!
Что за бред? Ну давайте еще тигров будем называть «полосатыми львами», чтоб нашим, родным ветеранам-танкистам в лицо не плевать. Идиотизм, честное слово!
Покрытый подобными тестами код будет 100% изолирован и вы в любом случае сможете рефакторить отдельный кусок персистенс-лэйера или бизнесс-объекта в дальнейшем без страха поломать систему в целом. Я говорю именно об этом. Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
Я лишь говорю о том, что если у вас на руках есть говнокод — он в 99% случаев будет без юнит-тестов ;-)
Переписывание кусков кода возможно, но вы этим обрекаете себя на анальные муки в случайные моменты времени, когда из-за вашего свежего, «правильного» решения будут ломаться все новые и новые «неправильные» куски системы, абсолютно не связанные, на первый взгляд, с переписанным кодом.
Посему, копание в работающем говнокоде почти всегда требует от разработчика одного и только одного — писать новый говнокод, вставляя костыли и распорки для существующей системы.
И дело тут вовсе не во времени. Если бы времени было достаточно — вопрос о копании в говнокоде просто не стоял бы, но его почти всегда нет.
Если есть запущенный проект с говнокодом, но без тестов — он в 99% случаев не поддается модульному рефакторину, ибо для рефакторинга нужна оттестированная изоляция модулей! Если же проект имеет юниты — проект в принципе уже не говнокодный.
Если бы меня кто-то пырнул карандашом — меня бы меньше всего интересовало переименование карандаша в ручку!