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

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

L>>Все же этому форуму очень не хватает смайлика "рука лицо".

Y>Абсолютно согласен. Вот вы, например, пишите, что заявление топикстартера "не соответствует <действительности> чуть более, чем полностью" и тут-же парой строчек ниже сообщаете, что да, прийдётся на каждый пук писать прокси и интерфейсы выделять и, следовательно, как-то мапить их на классы, а там уже и IOC фреймворк для этого а значит, и т.с. вроде как и прав и всё соответствует действительности чуть более чем полностью...

тут и двойной рукилицо не хватит.

Чтобы код был тестируем, он должен удовлетворять некоторым критериям тестируемости. Каждый юнит должен быть достаточно изолирован и самостоятелен и не требовать атомной электростанции для запуска. При этом внешние зависимости удобно заменять заглушками или воображалами (для чего, собственно, и выделяются интерфейсы).

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

В результате получается модульный код, разбитый на изолированные юниты с четко разграниченной ответственностью.

А вот это вот

На практике я почему-то вижу, что эта пресловутая "слабосвязанность" достигается именно тем, что описал топик стартер: какой-то горой никому(кроме тестов) не нужных итерфейсов один в один повторяющих методы класса, абстракций, прокси, прокси на прокси и т.д.
Еще очень хорошая практика для тестируемости делать приватные приватные переменные не совсем приватными(иначе как же тест их замокает?). Апофеозом адхитектуры для тестирования может стать вообще отказ от ООП: есть отдельно какие-то данные, есть отдельно набор методов-функций разной степени чистоты. Всё отлично изолировано, всё хорошо тестируется, всё непойми как работает(и не работает).

исключительно Ваши слова и надо их мне приписывать. Не видели приличных проектов с тестами — так и напиште, но не надо свой негативный опыт проецировать на всех.

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

А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками

Моки нужны, если тестировать "сверху вниз" (top-down): сначала фронтенд системы с моками вместо всех нижележащих слоёв, потом подцеплять следующий слой и заменять моками то, что под ним и т.д. Достоинство: возможность быстрого прототипирования морды лица. Недостатки: надо много моков; поведение реальных компонент может отличаться от поведения моков.

Моки не нужны, если тестировать "снизу вверх" (bottom-up): сначала тестируем нижний слой, затем цепляем к нему сверху тот слой, что над ним, и тестируем его (по сути — тестируем уже интеграцию двух слоёв) и т.д. Достоинства: не нужны моки; тестируется реальная система без заглушек. Недостаток: при разработке снизу вверх нельзя быстро состряпать морду лица для заказчика.

Подробнее см. в книге: Myers — The Art Of Software Testing — 2е издание (2004). Я сам всегда работаю "снизу вверх", в т.ч. гоняю тесты на реальной базе данных (т.е. даже здесь без моков). А стремление "быстро показать морду лица заказчику" считаю очковтирательством.

Здравствуйте, Аноним, Вы писали:
А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы.
А>Насколько это вообще соответствует действительности?
юнит-тесты нужны там где проект подразумевает большую текучку кадров и периодическую передачу проекта от одной команды к другой. то есть если изначально планируется делать гавно. ничего плохого в этом нет, далеко не каждая компания может сделать не гавно, а юнит-тесты помогут завершить проект.
в случае когда проект незнаком, в нем почти никто не разбирается и в нем много раз все менялось разными ведущими программистами, приходится коммитить практически вслепую, только догадываясь какие последствия это может вызвать. в случае же когда девелоперы понимают что делают нужны не юнит-тесты, а тесты другого рода — производительности, юзабилити и другого.

Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту

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

__>Здравствуйте, Аноним, Вы писали:
А>>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы.
А>>Насколько это вообще соответствует действительности?
__>юнит-тесты нужны там где проект подразумевает большую текучку кадров и периодическую передачу проекта от одной команды к другой. то есть если изначально планируется делать гавно. ничего плохого в этом нет, далеко не каждая компания может сделать не гавно, а юнит-тесты помогут завершить проект.
__>в случае когда проект незнаком, в нем почти никто не разбирается и в нем много раз все менялось разными ведущими программистами, приходится коммитить практически вслепую, только догадываясь какие последствия это может вызвать. в случае же когда девелоперы понимают что делают нужны не юнит-тесты, а тесты другого рода — производительности, юзабилити и другого.

Здравствуйте, BluntBlind, Вы писали:
BB>Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту

проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.

все

никакого толка от юнит-тестов нет

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

__>проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.

У меня для тебя две новости. одна — просто плохая. А другая — очень, очень плохая.

Во первых, у вас тут не юнит-тесты, а черт знает что.
Вторая — ты продемонстрировал классический случай извлечения выводов о творчестве ВИА "Битлз" на основе насвистанного дико фальшивящим Рабиновичем по междугороднему телефону на декадно-шаговой АТС.

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

__>никакого толка от юнит-тестов нет

Слава роботам! Они не ошибаются.

Есть куча проектов, которые успешны без юнит-тестов. Но это не значит, что от них нет толку.
То, что ты описал не юнит-тесты — это КОРЯВЫЕ интеграционные или функциональные тесты, которые просто построены на фреймворке для юнит-тестирования.
Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе.

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

__>Здравствуйте, BluntBlind, Вы писали:
BB>>Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту

__>проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.

__>все

__>никакого толка от юнит-тестов нет

Здравствуйте, BluntBlind, Вы писали:
BB>Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе.
ну это какие-то странные разговоры — тебе это не нравится, просто потому, что ты это не распробовал. мне юнит-тесты нравятся так же, как песни Укупника. я не думаю, что работая с ними больше я полюблю их

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

__>Здравствуйте, BluntBlind, Вы писали:
BB>>Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе.
__>ну это какие-то странные разговоры — тебе это не нравится, просто потому, что ты это не распробовал. мне юнит-тесты нравятся так же, как песни Укупника. я не думаю, что работая с ними больше я полюблю их

Да просто в качестве аргументов против юнит-тестов, ты приводишь неудачные примеры применения НЕ юнит-тестов.

Здравствуйте, BluntBlind, Вы писали:
BB>Да просто в качестве аргументов против юнит-тестов, ты приводишь неудачные примеры применения НЕ юнит-тестов.
да почему. там именно юнит-тесты, написанные специально обученными людьми. берется класс и тестируется
в большинстве случаев тест тривиален и бесполезен, но для покрытия и для возможного расширения класса он все равно пишется

кто-то утверждает, что юнит-тесты-де очень полезны. я вижу что они вообще бесполезны. будь они полезными я бы наблюдал хоть капельку какой-то полезности, мне так кажется.

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

__>да почему. там именно юнит-тесты, написанные специально обученными людьми. берется класс и тестируется
__>в большинстве случаев тест тривиален и бесполезен, но для покрытия и для возможного расширения класса он все равно пишется

__>кто-то утверждает, что юнит-тесты-де очень полезны. я вижу что они вообще бесполезны. будь они полезными я бы наблюдал хоть капельку какой-то полезности, мне так кажется.

Лично я пишу тесты, если логика достаточно сложная, чтобы я мог в ней ошибиться (это относится и к сложным бизнес-модулям, и к крошечным утилитам типа преобразования GUID из текстового вида в двоичный, в которых тем не менее есть шанс лопухнуться). Как частный случай этого правила (напомнило твоим пассажем про тривиальность и бесполезность) — если есть шансы, что в будущем тестеры найдут глюк в данной подсистеме, я пишу тест-заглушку просто для того, чтобы тот, кто будет этот глюк править, мог быстро его скопипастить и вписать свои данные, не разбираясь с написанием всей обвязки теста с нуля.

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

__> я вижу что они вообще бесполезны. будь они полезными я бы наблюдал хоть капельку какой-то полезности, мне так кажется.

На основе набора странных функциональных и интеграционных тестов делать вывод о полезности юнит-тестов? Это примерно как делать вывод о вкусе устриц, попробовав жареной плотвы.

Здравствуйте, landerhigh, Вы писали:
L>На основе набора странных функциональных и интеграционных тестов делать вывод о полезности юнит-тестов? Это примерно как делать вывод о вкусе устриц, попробовав жареной плотвы.
ну приведите пример из вашей жизни как выглядели правильные тесты и чем конкретно они помогли

Здравствуйте, __kot2, Вы писали:
__>ну приведите пример из вашей жизни как выглядели правильные тесты и чем конкретно они помогли
Видео 40 минут, там про TDD, мне оно в свое время сильно помогло.
http://vimeo.com/9541997#at=0

А вообще, что-то доказывать тебе сложно. Юнит-тесты очень практичная вещь и агитировать за них простыми обсуждениями в форуме малоэффективно.
У меня есть только такие доводы:

1. Огромное кол-во проектов использует юнит-тесты.
2. Многие программисты осознанно пишут юнит-тесты, хотя это для них, как бы дополнительная работа, еще больше кода, тем не менее ...
3. Посмотри как развита инфраструктура, утилиты и фремворки для написания, поддержания, запуска и анализа тестов.
4. Ты только погугли и удивись, как много статей (хороших и плохих) и книг написано про это.
5. Не думай, что тебе это не подходит т.к. у тебя особенный проект или команда, процентов на 99 ты ошибаешься

Т.е. работа кипит, все используют, а ты вот не видишь пользы, веротяно ты просто заблуждаешься и сделал неверные выводы.

Здравствуйте, BluntBlind, Вы писали:
BB>А вообще, что-то доказывать тебе сложно. Юнит-тесты очень практичная вещь и агитировать за них простыми обсуждениями в форуме малоэффективно.
BB>У меня есть только такие доводы:

BB>1. Огромное кол-во проектов использует юнит-тесты.
BB>2. Многие программисты осознанно пишут юнит-тесты, хотя это для них, как бы дополнительная работа, еще больше кода, тем не менее ...
BB>3. Посмотри как развита инфраструктура, утилиты и фремворки для написания, поддержания, запуска и анализа тестов.
BB>4. Ты только погугли и удивись, как много статей (хороших и плохих) и книг написано про это.
BB>5. Не думай, что тебе это не подходит т.к. у тебя особенный проект или команда, процентов на 99 ты ошибаешься
социальное доказательство? в стиле: все любят Гитлера, почему ты не любишь?
причем для меня оно не работает — я много команд видел, конечно же люди тестируют что делают и иногда очень тщательно, но не юнит-тестами

я же просил конкретные примеры привести — в двух словах — как по-вашему должны писаться грамотные юнит-тесты и какие конкретно проблемы они помогли найти
это ж основа всех основ — если нельзя какую-то вещь обяснить в двух словах, то и обьяснять не стоит — не разбираешься в ней, значит. 40 минут мозги компостировать на тему разработки софта может любой.

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

Здравствуйте, BluntBlind, Вы писали:
BB>Здравствуйте, __kot2, Вы писали:
__>>ну приведите пример из вашей жизни как выглядели правильные тесты и чем конкретно они помогли
BB>Видео 40 минут, там про TDD, мне оно в свое время сильно помогло.
BB>http://vimeo.com/9541997#at=0
что касается видео — это типичное руководство того, как засрать проект классами

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

BB>>Т.е. работа кипит, все используют, а ты вот не видишь пользы, веротяно ты просто заблуждаешься и сделал неверные выводы.

Гыгы, водка полезна! Миллионы мужиков не могут ошибаться!

__>да по большому счету никто их не использует, кроме, как я уже сказал, больших компаний руководствующхися современной адаптацией поговорки "больше бумажек — чище жопа" — "больше тестов, чище жопа". наличие покрытия тестами это официальная отмазка, что все работает, как надо, но ес-но по факту это вообще не так

Но однако же мне начинает казаться, что товарищ Кот2 — на самом деле не кот, а тролль.

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

BB>>http://vimeo.com/9541997#at=0
__>что касается видео — это типичное руководство того, как засрать проект классами

Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, __kot2, Вы писали:
BB>>>http://vimeo.com/9541997#at=0
__>>что касается видео — это типичное руководство того, как засрать проект классами
D>
да работал я просто с проектом, писанным как по видео этому
проект вроде и не делает ничего, в одного написать можно — ф-ти немного, а классов-классов-то, а каждому классу еще и по интерфейсу. файлов вагоны — вообще ничего не найдешь. каждый класс че-то делегирует и переадресует, потом сериализует, десериализует и опять делегирует и переадресует. и никто ничего не делает. только куда-то там инверсит контроль, абстрагирует и делегирует.
добавлял функцию новую одну по аналогии к существующим — 40 файлов закоммитил, из которых половина новых созданных