__>проект вроде и не делает ничего, в одного написать можно — ф-ти немного, а классов-классов-то, а каждому классу еще и по интерфейсу. файлов вагоны — вообще ничего не найдешь. каждый класс че-то делегирует и переадресует, потом сериализует, десериализует и опять делегирует и переадресует. и никто ничего не делает. только куда-то там инверсит контроль, абстрагирует и делегирует.
Смотрел я тут прокет дома один, вроде ничего и не делает, а одних материалов навезли уже два вагона, тут кран ставят, там электростанцию, а эти вообще зачем-то канализацию роют и все при деле и все заняты, а дом-то, дом-то где? Вторую неделю строят.
Здравствуйте, __kot2, Вы писали:
__>проект вроде и не делает ничего, в одного написать можно — ф-ти немного, а классов-классов-то, а каждому классу еще и по интерфейсу. файлов вагоны — вообще ничего не найдешь. каждый класс че-то делегирует и переадресует, потом сериализует, десериализует и опять делегирует и переадресует. и никто ничего не делает. только куда-то там инверсит контроль, абстрагирует и делегирует.
Ну это значит гуру ООП писал. =) Изгадить реализацией можно любую идею, сам понимаешь. О качестве идеи это ничего не говорит.
Да мне можно подумать нечем заняться, кроме как тебя убеждать. Не, я пас. Я свои дововды сказал, я тесты использую на мелких проекта тоже. Это бессмысленный разговор. Ты весь закрылся своими домыслами, страхами. Разжевывать тебе основы? Я думаю сам способен разобраться. Просто своими ответами ты показал свою некомпетентность в этом вопросе, но при этом требуешь каких то доказательств. Мне юниттесты нужны, я их использую, если тебе они не нужны, ну дык это твоя беда
Здравствуйте, __kot2, Вы писали:
__>я же просил конкретные примеры привести — в двух словах — как по-вашему должны писаться грамотные юнит-тесты и какие конкретно проблемы они помогли найти __>это ж основа всех основ — если нельзя какую-то вещь обяснить в двух словах, то и обьяснять не стоит — не разбираешься в ней, значит. 40 минут мозги компостировать на тему разработки софта может любой.
BB>>Т.е. работа кипит, все используют, а ты вот не видишь пользы, веротяно ты просто заблуждаешься и сделал неверные выводы. __>да по большому счету никто их не использует, кроме, как я уже сказал, больших компаний руководствующхися современной адаптацией поговорки "больше бумажек — чище жопа" — "больше тестов, чище жопа". наличие покрытия тестами это официальная отмазка, что все работает, как надо, но ес-но по факту это вообще не так
L>Смотрел я тут прокет дома один, вроде ничего и не делает, а одних материалов навезли уже два вагона, тут кран ставят, там электростанцию, а эти вообще зачем-то канализацию роют и все при деле и все заняты, а дом-то, дом-то где? Вторую неделю строят.
я занимался саппортом проекта, который, можно сказать, был завершен и давно не менялся
когда ты входишь в дом ты почему-то идешь в подвал, потом поднимаешься пешком на чердак, потом едешь на обычно нерабочем лифте на третий этаж, с третьего этажа по веревкам лезешь к себе домой на пятый
L>Может, тебе другую работу поискать, а?
умные люди, я смотрю, полезли. и все с ценными советами
Здравствуйте, BluntBlind, Вы писали: BB>Да мне можно подумать нечем заняться, кроме как тебя убеждать. Не, я пас. Я свои дововды сказал, я тесты использую на мелких проекта тоже. Это бессмысленный разговор. Ты весь закрылся своими домыслами, страхами. Разжевывать тебе основы? Я думаю сам способен разобраться. Просто своими ответами ты показал свою некомпетентность в этом вопросе, но при этом требуешь каких то доказательств. Мне юниттесты нужны, я их использую, если тебе они не нужны, ну дык это твоя беда
я не прошу меня убеждать. я вообще человек не упертый. меня легко переубедить простым примером. он вполне мог бы уложиться в этим несколько предложений, где вы расписывали о том, какой я плохой и какой вы хороший. мне это не интересно.
Здравствуйте, dimgel, Вы писали: D>Ну это значит гуру ООП писал. =) Изгадить реализацией можно любую идею, сам понимаешь. О качестве идеи это ничего не говорит.
ну, скажем так, такой подход провоцирует делать простые вещи максимально сложным образом.
вот понадобился человеку репортер, так и писал бы репортер. так нет, наворотил классов вагон, будто от этого чем-то лучше стало.
Здравствуйте, __kot2, Вы писали:
__>вот понадобился человеку репортер, так и писал бы репортер. так нет, наворотил классов вагон, будто от этого чем-то лучше стало.
class Reporter
{
// 100500 методов, полей и прочие спагетти
}
Здравствуйте, landerhigh, Вы писали: L>Так, что ли?
на у разве созданные классы занимаются только кодом репортера?
SimpleReportBuilder, SimpleReportSender, IReportRepository, IReportBuilder, IReportSender это все очень надо для репортера, да? Мелькнувший где-то интерфейс IMailer — красота просто. как без него-то?
а как красиво и понятно выглядит Main .. создается модуль, kernel, биндятся обьекты. мечта просто.
красота она достигается не тогда, когда нечего добавить, а когда нечего убрать
Да это же пример! Ну ты прикинь все это обрастет кучей функциональности, авторизация, ексепшины, логирование, еще что-то. Эх ...
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, landerhigh, Вы писали: L>>Так, что ли? __>на у разве созданные классы занимаются только кодом репортера? __>SimpleReportBuilder, SimpleReportSender, IReportRepository, IReportBuilder, IReportSender это все очень надо для репортера, да? Мелькнувший где-то интерфейс IMailer — красота просто. как без него-то?
__>а как красиво и понятно выглядит Main .. создается модуль, kernel, биндятся обьекты. мечта просто.
__>красота она достигается не тогда, когда нечего добавить, а когда нечего убрать
Здравствуйте, BluntBlind, Вы писали: BB>Да это же пример! Ну ты прикинь все это обрастет кучей функциональности, авторизация, ексепшины, логирование, еще что-то. Эх ...
ну я и говорю это рождает карго-культ, когда люди не могут создать ни одну сущность без какого-нить репозитория и интерфейса. делается простая вещь, а там тебе и какой-нить ISender и IMailer и Builder забабахают, да все это еще и инициализируется через задницу так что не поймешь вообще откуда оно в данном месте берется
Здравствуйте, BluntBlind, Вы писали:
BB>Да это же пример! Ну ты прикинь все это обрастет кучей функциональности, авторизация, ексепшины, логирование, еще что-то. Эх ...
Кот2 сказал, что поддерживает давно написанное, так что по условию задачи не обрастёт. Справедливости ради, я тут в соседней ветке срусь с архитекторами
, которые тоже готовы впихивать привычные им паттерны всюду без разбору — где надо и где не надо. А ещё есть такая либа log4j, от одного упоминания которой меня начинает тошнить: тоже очень концептуально правильно сделана, чёрт ногу сломает.
Здравствуйте, BluntBlind, Вы писали:
__>>ну приведите пример из вашей жизни как выглядели правильные тесты и чем конкретно они помогли BB>Видео 40 минут, там про TDD, мне оно в свое время сильно помогло. BB>http://vimeo.com/9541997#at=0
Вы, случаем, не его автор? Я уже второй раз вижу от вас эту ссылку.
Самое обычное видео евангелистов, я бы даже сказал — мегастандартное. Такого в интернетах миллионы. Только не калькулятор разве что пишут.
Re[12]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, landerhigh, Вы писали:
Y>>Абсолютно согласен. Вот вы, например, пишите, что заявление топикстартера "не соответствует <действительности> чуть более, чем полностью" и тут-же парой строчек ниже сообщаете, что да, прийдётся на каждый пук писать прокси и интерфейсы выделять и, следовательно, как-то мапить их на классы, а там уже и IOC фреймворк для этого а значит, и т.с. вроде как и прав и всё соответствует действительности чуть более чем полностью... L>тут и двойной рукилицо не хватит.
L>Перевожу — никаких спагетти. Выделение интерфейсов в целях разграничения ответственности при сохранении зависимости, что само по себе хорошо более чем всегда безотносительно наличия тестов.
Замечательно. Давайте писать хорошую архитектуру. И жить дружно. Все согласны. Особенно хорошо это звучит при "безотносительно тестов".
L>В результате получается модульный код, разбитый на изолированные юниты с четко разграниченной ответственностью.
Однако. Сам собой "получается". Прилетает волшебник в голубом вертолёте и у нас магически получится кило эскимо.
Вот есть у нас тот самый непродуманый публичный контракт в виде мешанины полей и методов дёргающих кучу других сущностей и делающих всё и ничего. Который вы называете "спагетти". Пишем юнит-тесты в лоб: публичный контракт один-в-один выносится в интерфейс(который interface). Все new Foo() заменили на Resolve<IFoo>();
Что изменилось? Да ничего не изменилось. Зависимости как были так и остались... есть-есть, не обольщайтесь, просто они слегка не так выглядят. Наш метод ведь как работал с двадцатью семью другими сущностями так и работает, а то, что получились они не "прямым" созданием а передались они через di контейнер/контруктор/параметр или еще как и это как-бэ не зависимости — это заблуждение. Архитетктура как была г. так и осталась(а с чего ей меняться-то?). Осталась святая вера в то, что вон то коричневое на эскимо волшебника — всё таки шоколад а не архитектура, потому что ведь юниттесты, а там оно как-то само по себе "в результате получается".
Забегая вперёд, на возможный аргумент "а мы при юнит-тестах перелопатим класс и всё по уму сделаем/при TDD изначально спроектируем как надо" я с недоумением замечу, что при чём тут тесты, что вам мешало этим заняться раньше/изначально сделать? И откуда вдруг берётся гарантия, что тот же самый разработчик того Foo не прийдёт к точно такому же результату через TDD: будет точно так же добавлять в упомянутые спагетти метод за методом, только сначала кропотливо добавляя стотридцатьседьмой метод к IFoo и пропихивая в реализацию семнадцатый Resolve<I...> — от что, умнее стал или ответственнее?
Я не против тестов, но вот святая вера, что с тестами всё вдвойне лучше само по себе и при этом бесплатно(я так напомню, что разговор начался именно про "накладные расходы") — это ИМХО типичный карго-культ.
L>
L>На практике я почему-то вижу, что эта пресловутая "слабосвязанность" достигается именно тем, что описал топик стартер: какой-то горой никому(кроме тестов) не нужных итерфейсов один в один повторяющих методы класса, абстракций, прокси, прокси на прокси и т.д.
L>Еще очень хорошая практика для тестируемости делать приватные приватные переменные не совсем приватными(иначе как же тест их замокает?). Апофеозом адхитектуры для тестирования может стать вообще отказ от ООП: есть отдельно какие-то данные, есть отдельно набор методов-функций разной степени чистоты. Всё отлично изолировано, всё хорошо тестируется, всё непойми как работает(и не работает).
L>исключительно Ваши слова и надо их мне приписывать.
Я вам их и не приписывал. Не надо мне приписывать, что я вам их приписываю.
L>Не видели приличных проектов с тестами — так и напиште, но не надо свой негативный опыт проецировать на всех.
Замечательный у нас разговор. Я вам про вполне конкретные вещи, практики и проблемы, которые при этом возникают а в ответ только "рукалицо" и намёки.
А приличные проекты с тестами я видел, поверьте. Только там они применялись осознано и по делу а не потому, что "с тестами самa собой получается хорошая архитектура" и "все так делают".
Y>Вы, случаем, не его автор? Я уже второй раз вижу от вас эту ссылку.
Нет не автор. Просто в нем хорошо показан TDD.
Y>Самое обычное видео евангелистов, я бы даже сказал — мегастандартное.
И это плюс данного видео.
Y>Такого в интернетах миллионы. Только не калькулятор разве что пишут.
Миллионы, не встречал, и чтобы вот так коротко и емко.
А то что пишут не калькулятор, я уверен это осознанно автор сделал, т.к. противники/непонимающие TDD и сразу до этого докопаются, что нормальную систему так не напишешь, у всех же мега проекты, а не калькуляторы.
ЗЫ Я тебе ответил, но впредь пиши по-существу, а не всякую чушь типа таких видео миллионы, евангилисты и т.д и т.п. Или лучше вообще не пиши.
Re[2]: Проектирование системы с учетом юнит-тестирования
On 16.12.2012 9:46, __kot2 wrote:
> юнит-тесты нужны там где проект подразумевает большую текучку кадров и > периодическую передачу проекта от одной команды к другой. то есть если > изначально планируется делать гавно. ничего плохого в этом нет, далеко > не каждая компания может сделать не гавно, а юнит-тесты помогут > завершить проект. > в случае когда проект незнаком, в нем почти никто не разбирается и в нем > много раз все менялось разными ведущими программистами, приходится > коммитить практически вслепую, только догадываясь какие последствия это > может вызвать. в случае же когда девелоперы понимают что делают нужны не > юнит-тесты, а тесты другого рода — производительности, юзабилити и другого.
Нет ты не прав. А всегда пишу UT для себя.
Просто в 95% контор юнит тесты это такой кнут для програмеров, чтобы они
старались говнокод ваять более ни менее приемлемо, ну и частично
переложить на них тестирование (тестировщики обычно грамотнее в
социальном плане, чем програмеры и с успехом перекладывают свою
ответсвенность). В 5% они (юнит тесты) используются по назначению.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Vzhyk, Вы писали: V>Нет ты не прав. А всегда пишу UT для себя.
кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство. могу напомнить про эксперимент с обезьянами, которых водой обливали
вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний, где усатых разработчиков в сандалях нужно жестко пороть, чтобы они херню не делали. и то ведь умудряются. возможно, там они чем-то помогают. но если смотреть с позиции разумного, доброго и светлого, пока что ни одного довода, обьясняющего причину использования юнит-тестов названо не было.
Re[4]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Vzhyk, Вы писали: V>>Нет ты не прав. А всегда пишу UT для себя. __>кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство.
Я не буду ничего доказывать. Я расскажу как я использую юнит-тесты: http://www.rsdn.ru/forum/philosophy/4441775.1
Я пишу юнит тесты только для сложной логики. Еще часто бывает, что тест написать намного проще чем логику. В таких случаях модульные тесты писать категорически рекомендуется.
Писать же юнит тесты для метода на 10 мин смысла не имеет никакого. Лучше написать интеграционный тест сразу на весь/все сценарии которые ты разрабатываешь в данным момент.
...
Еще бывают случаи, когда логика простая, но ты знаешь, что тебе в ней ошибиться как два пальца. Например, я всегда путаюсь в кол-ве символов для substring (сколько символов вырезается или +-1?).
Для таких случаев у меня есть класс QuickTests с единственным пустым методом. Туда побыструхе пишется тест, прогоняется до "зелености" и тут же удаляется.
Есть случаи когда тест уж очень простой, логика -- отностиельно проста (смысл теста -- застраховать тебя от тупых ошибок). Пример -- нужно распарсить xml-ответ от внешнего сервиса. Тест написать элементарно (скопипастил ответ из браузера или SoapUI). Глупую ошибку сделать очень легко. Тест после прохождения либо удаляется либо остается для предотвращения ошибок регрессиии.
За год практически ничего не поменялось. Единсвенное, я стал писать юнит тестов еще меньше
В большинстве случаев достаточно факта что что-то не работает. С задачей уведомления о проблеме справляются интеграционные тесты. А их писать и поддерживать гораздо проще.
Можно обсудить.
P.S. __kot2, если не считать твое первое сообщение и пары других категоричных высказываний, я разделяю твою твою точку зрения.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, BluntBlind, Вы писали: BB>>Здравствуйте, __kot2, Вы писали: __>>>ну приведите пример из вашей жизни как выглядели правильные тесты и чем конкретно они помогли BB>>Видео 40 минут, там про TDD, мне оно в свое время сильно помогло. BB>>http://vimeo.com/9541997#at=0 __>что касается видео — это типичное руководство того, как засрать проект классами
А вы из той когорты, где боятся лишний класс создать? Наверное в одном файле по 10 nested-классов тоже пишете?
Здравствуйте, michael_isu, Вы писали: _>А вы из той когорты, где боятся лишний класс создать? Наверное в одном файле по 10 nested-классов тоже пишете?
я из той "когорты" что пишет не для себя, а для других. мне жалко время людей, которым приходится разбираться в моем коде. поэтому код должен быть прост и минимален.
