Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы.
Насколько это вообще соответствует действительности?
Re: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Аноним, Вы писали:
А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы.
А>Насколько это вообще соответствует действительности?
Не соответствует чуть более, чем полностью. Все поставлено с ног на голову в некотором роде.
Чтобы код был тестируем, он должен удовлетворять некоторым критериям тестируемости. Каждый юнит должен быть достаточно изолирован и самостоятелен и не требовать атомной электростанции для запуска. При этом внешние зависимости удобно заменять заглушками или воображалами (для чего, собственно, и выделяются интерфейсы).
В результате получается модульный код, разбитый на изолированные юниты с четко разграниченной ответственностью. Почти священный грааль программирования. Только разница в том, что получается он таким вовсе не в результате кропотливого планирования, а в результате итеративной разработки с применением юнит-тестов.
Здравствуйте, Аноним, Вы писали:
А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами
Акцент все-таки на том, что нельзя в общем случае взять непокрытую систему и покрыть ее юнит тестами, что бы потом сказать "вот юнит тесты для той системы". Система должна была быть специальным образом разработана, либо адаптирована к юнит тестированию.
A>придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками
Для всех классов — это, пожалуй, слишком сильное утверждение. Зависит от связанности модулей (юнитов).
A>во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы.
Не вдаваясь в тонкости терминологии — нет, не обязательно. Но бывает удобно.
А>Насколько это вообще соответствует действительности?
Более-менее соответствует. Степень соответствия специфична для конкретных систем и их создателей.
Видал систему, написанную без единого теста, но так, будто бы ее писали TDD и после завершения выкинули все тесты. Не скажу что там была толпа интерфейсов. IoC применялся, но без фреймворков.
Re[2]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Brutalix, Вы писали:
B>Здравствуйте, landerhigh, Вы писали:
L>>Чтобы код был тестируем, он ....
B>А не посоветуешь умную книжку, желательно по-проще, с карнтинками и с упором на выгоды юнит-тестов? (для агитации местного населения)
Книжки нет, но я довольно много писал об этом (и как раз занимался агитацией в своей команде. Успешно).
2. The Art of Unit Testing
Если собираешься пробивать эту тему, то лучше всего с ней подробнее разобраться. Там много чего полезного описано, включая "продавливание" юнит-тестов в командах.
3. Параметризованные юнит-тесты
Как сделать так, чтобы кода тестов было меньше, а смысла от них (и покрытия в том числе) — больше.
4. Управление зависимостями
Не совсем про юнит-тесты, а про дизайн, но поскольку юнит-тесты — это прежде всего хороший дизайн, то управление зависимостями играет тут ключевую роль.
5. Идеальная архитектура
Опять таки, одним из важных характеристик "хорошести" архитектуры явялется ее независимость, а значит тестируемость. Может тоже чего хорошего найдете.
Re[3]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Brutalix, Вы писали:
L>>Чтобы код был тестируем, он ....
B>А не посоветуешь умную книжку, желательно по-проще, с карнтинками и с упором на выгоды юнит-тестов? (для агитации местного населения)
Честно говоря, сам хочу найти. Не уверен, что такая существует. Это же сугубо практическая вещь, теорию на юнит-тестирование натягивать ИМХО бесполезно.
По опыту, агитация действует не очень. Лучше всего работает быстрый проект, которым рулит евангелист TDD или просто юнит-тестирования (в завсимости от публики ему может быть очень желательно быть еще и фашистом или просто диктатором)
Здравствуйте, landerhigh, Вы писали:
B>>А не посоветуешь умную книжку, желательно по-проще, с карнтинками и с упором на выгоды юнит-тестов? (для агитации местного населения)
L>Честно говоря, сам хочу найти. Не уверен, что такая существует. Это же сугубо практическая вещь, теорию на юнит-тестирование натягивать ИМХО бесполезно. L>По опыту, агитация действует не очень. Лучше всего работает быстрый проект, которым рулит евангелист TDD или просто юнит-тестирования (в завсимости от публики ему может быть очень желательно быть еще и фашистом или просто диктатором)
В упомянутой выше The Art of Unit Testing есть целый раздел по поводу продвижения (как я уже сказал выше).
А продвигать приходится как всегда: примером, причем желательно собственным и позитивным (т.е. они для вас должны приносить пользу).
Как-то недавно пробегал твит от кого-то из TDD-гуру: что если бы каждый раз, когда юнит-тест находил баг, человек бы подпрыгивал и кричал "Ура! Тест сработал!", то все значительно лучше бы осознавали их ценность
Если серьезно, то очень здорово покрыть тестами (юнит или интеграционными) наиболее хрупкие части системы, и показывать их преимущества изо дня в день.
Помимо этого может сработать ненавязчивое проталкивание этой техники во время код- или дизайн-ревью с помощью вопросов:
Ты: — Вот смотри, как бы ты писал юнит тест для своего класса/модуля?
Он: — Ну, не знаю, а зачем мне это нужно, да и вообще, сложно это...
Ты: — Ну раз ты не можешь написать юнит-тест, значит ты не можешь думать о своем классе/модуле в изоляции. А значит у него нет четких входов/выходов (или их слишком много), что говорит о проблемах с дизайном. Если модуль тяжело протестировать, то его будет тяжело (или невозможно) использовать в другом контексте, что ставит полный крест на повторном использовании.
Он: — Ну ладно, но все равно, как-то не хочется из-за таких "мелочей" тратить время.
Ты: — А ты посмотри с другой стороны: ты не просто тратишь время один раз, ты бережешь его для себя и своей команды в будущем. Ведь тесты можно использовать, как еще один клиент твоего класса/модуля. Нормальный тест будет является своего рода источником спецификации системы и мы можем использовать эту информацию повторно. Да и вообще, ведь тебе, чтобы доделать задачу, все равно придется потратить время на запуск всей этой сложной системы, причем делать это придется каждый раз и не только тебе, но и твоим коллегам. Юнит-тест может просто сберечь твое время, поскольку ты сможешь потратить времени в 10 раз меньше на проверку этой маленькой функции.
Он: — Ну, не убедил окончательно... А какие есть у этого дела еще выгоды?
Ты: — Ну, если этого мало Давай подумаем об интеграции. Ведь у нас постоянная проблема с параллельной разработкой упирается в интеграцию. Вспомни, как ты с Васей долелали куски одной задачи и начали их интегрировать. На задачу ушло неделю, а потом вы бились головами еще три недели, чтобы объединить эти два куска и заставить их работать вместе. Тест дают некоторый формализм и значительно упрощают интеграцию. Ты вспомни того же Буча: любая сложная система строится на основе проверененных маленьких строительных блоков. А как нам получить проверенные строительные былоки, если мы не будем тестировать их вначале в изоляции? Вот и получается, что у нас есть огромная плоская система, на которой мы постоянно проверяем эффект бабочки: изменяем одну часть системы, а в продакшне летит совершенно другая ее часть.
Ну и не забывай о рефакторинге: без тестов (юнит и интеграционных) мы не можем зафиксировать текущее поведение, чтобы изменить ее внутреннюю реализацию. Тесты выступают в роли таких себе "тисков", в которые мы зажимаем систему, чтобы она не дергалась. Без этого процесс рефакторинга становится совершенно неуправляемым, а ведь мы-то с тобой знаем, что придет время, когда мы с тобой скажем: "А давай-ка тут немного переделаем!", так давай заложимся на это с самого начала.
Он: — Ну ладно, так давай подытожим, чего же мы получим в результате.
Ты: — Ну, ладно, вот небольшой список пользы юнит-тестов:
1. Юнит-тесты — лакмусовая бумажка плохого дизайна. Если у нас нет мыслей, как это дело потестить, то с дизайном явно что-то не то.
2. Юнит-тесты — дополнительный источник спецификации системы. Код сам по себе не может быть правильным или не правильным. Все зависит от того, что мы от него ожидаем (а тесты как раз и показывают "ожидаемое" поведение системы).
3. Юнит-тесты помогают использовать повторно наши усилия: подумать раз и заперсистентить наши мысли в форме тестов.
4. Юнит-тесты могут даже ускорить разработку. Если для проверки фичи нужно 5 минут, то 20 минут на написание теста с последующей секундной проверкой будет более эфективным использованием времени даже в краткосрочной перспективе.
5. Юнит-тесты упрощают интеграцию. Хорошо продуманные кусочки легко объединять и, что самое главное, легко "перемещать" из одного места системы в другое.
6. Юнит-тесты — это — это необходимый background для рефакторинга. Без них рефакторинг превращается в серьезную авантюру.
Но есть и явный вред от них:
1. Плохие юнит-тесты — хуже чем их отсутствие. Они должны тестировать абстракцию, и не вдаваться в подробности реализации. Тест, который постоянно падает будет удален. Тест, в котором невозможно разобраться, будет удален. Тест, который падает через раз — будет удален. Тест, который работает полдня — будет удален. Тест, который постоянно ломается при несущественных изменениях реализации — будет удален.
2. Тесты — не самоцель. Не гонитесь за покрытием, будьте прагматиками. Тестируйте важные части системы и не тестируйте глупости.
А еще рекомендую послушать следующие два подкаста Кента Бека (они очень круто меняют взгляд на юнит тесты):
L>Честно говоря, сам хочу найти. Не уверен, что такая существует. Это же сугубо практическая вещь, теорию на юнит-тестирование натягивать ИМХО бесполезно. L>По опыту, агитация действует не очень. Лучше всего работает быстрый проект, которым рулит евангелист TDD или просто юнит-тестирования (в завсимости от публики ему может быть очень желательно быть еще и фашистом или просто диктатором)
Ни фашист, ни диктатор работать не будет. Чтобы тесты заработали нужно, чтобы люди загорелись. В противном случае, народ накалбасит вам два ведра говно-тестов, стоимость поддержки которых будет выше, чем стоимость поддержки самой системы. Хрупкие тесты — страшная вещь, так что силой здесь ничего не сделать.
Re[5]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, SergeyT., Вы писали:
ST>Здравствуйте, landerhigh, Вы писали:
L>>Честно говоря, сам хочу найти. Не уверен, что такая существует. Это же сугубо практическая вещь, теорию на юнит-тестирование натягивать ИМХО бесполезно. L>>По опыту, агитация действует не очень. Лучше всего работает быстрый проект, которым рулит евангелист TDD или просто юнит-тестирования (в завсимости от публики ему может быть очень желательно быть еще и фашистом или просто диктатором)
ST>Ни фашист, ни диктатор работать не будет. Чтобы тесты заработали нужно, чтобы люди загорелись. В противном случае, народ накалбасит вам два ведра говно-тестов, стоимость поддержки которых будет выше, чем стоимость поддержки самой системы. Хрупкие тесты — страшная вещь, так что силой здесь ничего не сделать.
Вот для этого и нужен диктатор-фашист. Люди, прежде чем загореться, будут саботажничать. Намеренно или невольно, но это неважно. Вот этот саботаж и нужно давить в зародыше, и в то же время попытки написания тестов просто на "получи и отвали" должны пресекаться самым жестким образом.
Обычно для всего этого достаточно простого менторинга — люди и правда загораются и сами начинают колбасить тесты, и остается лишь стоять в сторонке да поглядывать. Только достоачно одного дятла, чтобы все испортить. Вот для этих дятлов и нужны ежовые рукавицы.
Здравствуйте, SergeyT., Вы писали:
ST>Ну и не забывай о рефакторинге: без тестов (юнит и интеграционных) мы не можем зафиксировать текущее поведение, чтобы изменить ее внутреннюю реализацию. ST>6. Юнит-тесты — это — это необходимый background для рефакторинга. Без них рефакторинг превращается в серьезную авантюру.
Тут не без нюансов. Если в рамках рефакторинга меняется дизайн приложения (что чаще всего и бывает), то это требует изменений в юнит-тестах. И обещанных гарантий фиксации поведения уже нет.
На одном из проектов нам в наследство досталась куча сильносвязного кода с багами и без тестов. Было решено сделать глубокий рефакторинг. Из соображений "зафиксировать текущее поведение" заказчик решил покрыть все тестами. Более бессмысленного занятия я не припомню...
Re[6]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, artelk, Вы писали:
A>Тут не без нюансов. Если в рамках рефакторинга меняется дизайн приложения (что чаще всего и бывает), то это требует изменений в юнит-тестах. И обещанных гарантий фиксации поведения уже нет. A>На одном из проектов нам в наследство досталась куча сильносвязного кода с багами и без тестов. Было решено сделать глубокий рефакторинг. Из соображений "зафиксировать текущее поведение" заказчик решил покрыть все тестами. Более бессмысленного занятия я не припомню...
Потому что не надо юнит-тесты пихать в все щели.
В вашем случае помог бы behaviour(или как он правильно называется?)-подход: на "верхние" интерфейсы пишутся тестовые сценарии, прогоняющие типичные use-cases, юнит-тесты выкидываются и дальше все потроха рефакторятся с единственной оглядкой на проходжение сценариев.
Re[4]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, pik, Вы писали:
B>>А не посоветуешь умную книжку, желательно по-проще, с карнтинками и с упором на выгоды юнит-тестов? (для агитации местного населения) pik>с картинками pik>http://msdn.microsoft.com/en-us/library/jj159345.aspx
Кстати об этой книжке- стоит на нее время тратить???
Кто нибудь хотябы частично реализовал предложенное в ней на реальных проектах?
Поясню свой интерес — у меня тут появился проект уже запущеный в продакшен (MVC3 + DAO самописный (Postgree/MySQL — plain sql /stored procedures) без ORM )
я на пректе не работал но сейчас буду единственным его мейнтейнером.
Т.к. новые фичи + исправление старых косяков ляжет на меня то как говорится "не навреди" т.е. не хочется при исправлении багов и добавлении фич
поломать уже работающий функционал и поэтому имхо стоит обложить проект хотя бы высокоуровневыми интеграционными тестами что бы на ранней стадии
увидеть что что то пошло не так.
Может кто уже ходил по тем граблям по которым мне предстоит так что подскажите в какую сторону двигаться?
NetDigitally yours ....
Re[5]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Jericho113, Вы писали:
J>Кстати об этой книжке- стоит на нее время тратить??? J>Кто нибудь хотябы частично реализовал предложенное в ней на реальных проектах?
я то сам толъко пробежался по ней и рекомендации датъ не могу.
был на МС-конференции там нам это расписывали как чудо инновации МСа
собственно что имеем? а то что те юнит-тесты котрые ранъше вручную писали и код для этого "нагибали" затем или выкидывали или отделъно от проекта надолго кудато запихивали — теперъ
имеют автоматический механизм и целую кучу инструментария, всё хранится с проектом и всегда готово к запуску. преимущества конечно существенные. но это не интергарционны тесты и то что вы описали — это не то. вы не хотите ломатъ старые структуры и созданный код рефакторизироватъ а толъко пару тестов для скорре успокоения души так сказатъ написатъ. такой подход с точки зреноя МС и коекаких существующих авторов книг — не правилен. старый код(legacy code) нелъзя еффектифно без рефакторинга юнит тестами покрытъ. естъ мнение что именно юнит-тесты помогают даже старый код как положено рефакторироватъ(или как там по русски?)
короче: если речъ идёт о юниттестировании — то вам придётся весъ код перелопатитъ и много времени инвестироватъ в это но тогда будет и еффект. код не трогатъ а пару интеграционных тестов завести — по моему смысла совсем не имеет или оченъ мало ибо это и так всегда разработчиком делается и вполеслдствии тестерами, всё осталъниое в более-менее сложных пректах — нереалъно
Re[7]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Yoriсk, Вы писали:
Y>Потому что не надо юнит-тесты пихать в все щели.
Надо, если их делать с самого начала проекта. Y>В вашем случае помог бы behaviour(или как он правильно называется?)-подход: на "верхние" интерфейсы пишутся тестовые сценарии, прогоняющие типичные use-cases, юнит-тесты выкидываются и дальше все потроха рефакторятся с единственной оглядкой на проходжение сценариев.
Ну да, все закончилось функциональными и самыми "общими" интеграционными тестами.
Я это к тому, что при глубоком рефакторинге юнит-тесты нифига не помогают что-то там зафиксировать.
При рефакторинге они помогают главным образом в другом — проверить насколько удачный дизайн получился после рефакторинга, т.е.
1. Слабосвязный (и, как следствие, гибкий), благодаря чему юнит-тесты легко писать
2. Простой, благодаря чему юнит-тесты легко читать
Re[7]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Yoriсk, Вы писали:
Y>Потому что не надо юнит-тесты пихать в все щели.
Проблема в том, что апологеты юнит-тестирования как раз таки именно это и предлагают.
Y>В вашем случае помог бы behaviour(или как он правильно называется?)-подход: на "верхние" интерфейсы пишутся тестовые сценарии, прогоняющие типичные use-cases
Это называется функциональное тестирование.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Jericho113, Вы писали:
J>Кстати об этой книжке- стоит на нее время тратить???
Конкретно эту книжку не смотрел, но вообще MS P&P весьма вменяемые вещи обычно делает.
J>Кто нибудь хотябы частично реализовал предложенное в ней на реальных проектах?
Так это, оно ведь как раз на основе реально реализованных проектов пишется. Постфактум.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, artelk, Вы писали:
Y>>Потому что не надо юнит-тесты пихать в все щели. A>Надо, если их делать с самого начала проекта.
Угу. А если система есть а их нет, то надо начать с самого начала, написать никому не нужные юнит тесты потому что как же мы без священной коровы.
A>При рефакторинге они помогают главным образом в другом — проверить насколько удачный дизайн получился после рефакторинга, т.е.
Это, мягко говоря, спорно.
На практике я почему-то вижу, что эта пресловутая "слабосвязанность" достигается именно тем, что описал топик стартер: какой-то горой никому(кроме тестов) не нужных итерфейсов один в один повторяющих методы класса, абстракций, прокси, прокси на прокси и т.д.
Еще очень хорошая практика для тестируемости делать приватные приватные переменные не совсем приватными(иначе как же тест их замокает?). Апофеозом адхитектуры для тестирования может стать вообще отказ от ООП: есть отдельно какие-то данные, есть отдельно набор методов-функций разной степени чистоты. Всё отлично изолировано, всё хорошо тестируется, всё непойми как работает(и не работает).
Вобщем может быть так а может и иначе, лёгкость тестирования вам ничего не гарантирует.
A>2. Простой, благодаря чему юнит-тесты легко читать
Никогда не видели, как юниттесты легко читать, всё ими обложено, всё зелёное, а "в целом" всё падает чуть более чем постоянно?
Re[9]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Yoriсk, Вы писали:
Y>Здравствуйте, artelk, Вы писали:
Y>>>Потому что не надо юнит-тесты пихать в все щели. A>>Надо, если их делать с самого начала проекта.
Y>Угу. А если система есть а их нет, то надо начать с самого начала, написать никому не нужные юнит тесты потому что как же мы без священной коровы.
Все же этому форуму очень не хватает смайлика "рука лицо".
Здравствуйте, landerhigh, Вы писали:
L>Все же этому форуму очень не хватает смайлика "рука лицо".
Абсолютно согласен. Вот вы, например, пишите, что заявление топикстартера "не соответствует <действительности> чуть более, чем полностью" и тут-же парой строчек ниже сообщаете, что да, прийдётся на каждый пук писать прокси и интерфейсы выделять и, следовательно, как-то мапить их на классы, а там уже и IOC фреймворк для этого а значит, и т.с. вроде как и прав и всё соответствует действительности чуть более чем полностью...
Re[11]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Yoriсk, Вы писали:
Y>Здравствуйте, landerhigh, Вы писали:
L>>Все же этому форуму очень не хватает смайлика "рука лицо".
Y>Абсолютно согласен. Вот вы, например, пишите, что заявление топикстартера "не соответствует <действительности> чуть более, чем полностью" и тут-же парой строчек ниже сообщаете, что да, прийдётся на каждый пук писать прокси и интерфейсы выделять и, следовательно, как-то мапить их на классы, а там уже и IOC фреймворк для этого а значит, и т.с. вроде как и прав и всё соответствует действительности чуть более чем полностью...
тут и двойной рукилицо не хватит.
Чтобы код был тестируем, он должен удовлетворять некоторым критериям тестируемости. Каждый юнит должен быть достаточно изолирован и самостоятелен и не требовать атомной электростанции для запуска. При этом внешние зависимости удобно заменять заглушками или воображалами (для чего, собственно, и выделяются интерфейсы).
Перевожу — никаких спагетти. Выделение интерфейсов в целях разграничения ответственности при сохранении зависимости, что само по себе хорошо более чем всегда безотносительно наличия тестов. Избавление от ситуаций, когда для создания какого-то модуля требуется сначала создать все остальные модули системы.
В результате получается модульный код, разбитый на изолированные юниты с четко разграниченной ответственностью.
А вот это вот
На практике я почему-то вижу, что эта пресловутая "слабосвязанность" достигается именно тем, что описал топик стартер: какой-то горой никому(кроме тестов) не нужных итерфейсов один в один повторяющих методы класса, абстракций, прокси, прокси на прокси и т.д.
Еще очень хорошая практика для тестируемости делать приватные приватные переменные не совсем приватными(иначе как же тест их замокает?). Апофеозом адхитектуры для тестирования может стать вообще отказ от ООП: есть отдельно какие-то данные, есть отдельно набор методов-функций разной степени чистоты. Всё отлично изолировано, всё хорошо тестируется, всё непойми как работает(и не работает).
исключительно Ваши слова и надо их мне приписывать. Не видели приличных проектов с тестами — так и напиште, но не надо свой негативный опыт проецировать на всех.
Здравствуйте, Аноним, Вы писали:
А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками
Моки нужны, если тестировать "сверху вниз" (top-down): сначала фронтенд системы с моками вместо всех нижележащих слоёв, потом подцеплять следующий слой и заменять моками то, что под ним и т.д. Достоинство: возможность быстрого прототипирования морды лица. Недостатки: надо много моков; поведение реальных компонент может отличаться от поведения моков.
Моки не нужны, если тестировать "снизу вверх" (bottom-up): сначала тестируем нижний слой, затем цепляем к нему сверху тот слой, что над ним, и тестируем его (по сути — тестируем уже интеграцию двух слоёв) и т.д. Достоинства: не нужны моки; тестируется реальная система без заглушек. Недостаток: при разработке снизу вверх нельзя быстро состряпать морду лица для заказчика.
Подробнее см. в книге: Myers — The Art Of Software Testing — 2е издание (2004). Я сам всегда работаю "снизу вверх", в т.ч. гоняю тесты на реальной базе данных (т.е. даже здесь без моков). А стремление "быстро показать морду лица заказчику" считаю очковтирательством.
Re: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Аноним, Вы писали: А>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы. А>Насколько это вообще соответствует действительности?
юнит-тесты нужны там где проект подразумевает большую текучку кадров и периодическую передачу проекта от одной команды к другой. то есть если изначально планируется делать гавно. ничего плохого в этом нет, далеко не каждая компания может сделать не гавно, а юнит-тесты помогут завершить проект.
в случае когда проект незнаком, в нем почти никто не разбирается и в нем много раз все менялось разными ведущими программистами, приходится коммитить практически вслепую, только догадываясь какие последствия это может вызвать. в случае же когда девелоперы понимают что делают нужны не юнит-тесты, а тесты другого рода — производительности, юзабилити и другого.
Re[2]: Проектирование системы с учетом юнит-тестирования
Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Аноним, Вы писали: А>>Почитав некоторое время про юнит-тестирование систем, сложилось впечатление что что-бы покрыть ее тестами придется во-первых для всех классов выделять интерфейсы что-бы имелась возможность заменять моками, во-вторых практически обязательно использование фреймворков для реализации IoC и моков т.к. иначе будет куча ручной работы. А>>Насколько это вообще соответствует действительности? __>юнит-тесты нужны там где проект подразумевает большую текучку кадров и периодическую передачу проекта от одной команды к другой. то есть если изначально планируется делать гавно. ничего плохого в этом нет, далеко не каждая компания может сделать не гавно, а юнит-тесты помогут завершить проект. __>в случае когда проект незнаком, в нем почти никто не разбирается и в нем много раз все менялось разными ведущими программистами, приходится коммитить практически вслепую, только догадываясь какие последствия это может вызвать. в случае же когда девелоперы понимают что делают нужны не юнит-тесты, а тесты другого рода — производительности, юзабилити и другого.
Re[3]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, BluntBlind, Вы писали: BB>Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту
проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.
все
никакого толка от юнит-тестов нет
Re[4]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.
У меня для тебя две новости. одна — просто плохая. А другая — очень, очень плохая.
Во первых, у вас тут не юнит-тесты, а черт знает что.
Вторая — ты продемонстрировал классический случай извлечения выводов о творчестве ВИА "Битлз" на основе насвистанного дико фальшивящим Рабиновичем по междугороднему телефону на декадно-шаговой АТС.
Есть куча проектов, которые успешны без юнит-тестов. Но это не значит, что от них нет толку.
То, что ты описал не юнит-тесты — это КОРЯВЫЕ интеграционные или функциональные тесты, которые просто построены на фреймворке для юнит-тестирования.
Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, BluntBlind, Вы писали: BB>>Пост домыслов и стереотипов. Либо был неудачный опыт использования тестов, либо его вообще не было. Не знаю еще как объяснить такую позицию, а главное доводы в ее защиту
__>проблем с доводкой приложений, завершением разработки в срок и наличием хронических глюков никогда не имел. принимал участие в разработке последний раз когда считал, около 40 проектов. сейчас больше полугода работаю в проекте где есть юнит-тесты. толку от них что мертвому припарки — они только тратят твое время, так как проходят где-то за полчаса. ни разу еще не было такого, чтобы юнит-тест упал и это дало бы инфу — что-то поломалось. обычно ломается сам юнит-тест из-за кода, который там соединяется с тестовым сервером, который че-то решил прилечь или же юнит-тест падает потому что мы где-то что-то в базу добавили и теперь нужно еще и юнит-тест обновить, чтобы циферка совпала.
__>все
__>никакого толка от юнит-тестов нет
Re[5]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, BluntBlind, Вы писали: BB>Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе.
ну это какие-то странные разговоры — тебе это не нравится, просто потому, что ты это не распробовал. мне юнит-тесты нравятся так же, как песни Укупника. я не думаю, что работая с ними больше я полюблю их
Re[6]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, BluntBlind, Вы писали: BB>>Можно я дам совет? Тебе лучше не писать в ветки про юнит-тесты, ты не знаешь что это такое. Хотя очень убедителен. Тебе действительно стоит разобраться в этом вопросе. __>ну это какие-то странные разговоры — тебе это не нравится, просто потому, что ты это не распробовал. мне юнит-тесты нравятся так же, как песни Укупника. я не думаю, что работая с ними больше я полюблю их
Да просто в качестве аргументов против юнит-тестов, ты приводишь неудачные примеры применения НЕ юнит-тестов.
Re[7]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, BluntBlind, Вы писали: BB>Да просто в качестве аргументов против юнит-тестов, ты приводишь неудачные примеры применения НЕ юнит-тестов.
да почему. там именно юнит-тесты, написанные специально обученными людьми. берется класс и тестируется
в большинстве случаев тест тривиален и бесполезен, но для покрытия и для возможного расширения класса он все равно пишется
кто-то утверждает, что юнит-тесты-де очень полезны. я вижу что они вообще бесполезны. будь они полезными я бы наблюдал хоть капельку какой-то полезности, мне так кажется.
Re[8]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>да почему. там именно юнит-тесты, написанные специально обученными людьми. берется класс и тестируется __>в большинстве случаев тест тривиален и бесполезен, но для покрытия и для возможного расширения класса он все равно пишется
__>кто-то утверждает, что юнит-тесты-де очень полезны. я вижу что они вообще бесполезны. будь они полезными я бы наблюдал хоть капельку какой-то полезности, мне так кажется.
Лично я пишу тесты, если логика достаточно сложная, чтобы я мог в ней ошибиться (это относится и к сложным бизнес-модулям, и к крошечным утилитам типа преобразования GUID из текстового вида в двоичный, в которых тем не менее есть шанс лопухнуться). Как частный случай этого правила (напомнило твоим пассажем про тривиальность и бесполезность) — если есть шансы, что в будущем тестеры найдут глюк в данной подсистеме, я пишу тест-заглушку просто для того, чтобы тот, кто будет этот глюк править, мог быстро его скопипастить и вписать свои данные, не разбираясь с написанием всей обвязки теста с нуля.
Re[8]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __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 — на самом деле не кот, а тролль.
Здравствуйте, dimgel, Вы писали: D>Здравствуйте, __kot2, Вы писали: BB>>>http://vimeo.com/9541997#at=0 __>>что касается видео — это типичное руководство того, как засрать проект классами D>
да работал я просто с проектом, писанным как по видео этому
проект вроде и не делает ничего, в одного написать можно — ф-ти немного, а классов-классов-то, а каждому классу еще и по интерфейсу. файлов вагоны — вообще ничего не найдешь. каждый класс че-то делегирует и переадресует, потом сериализует, десериализует и опять делегирует и переадресует. и никто ничего не делает. только куда-то там инверсит контроль, абстрагирует и делегирует.
добавлял функцию новую одну по аналогии к существующим — 40 файлов закоммитил, из которых половина новых созданных
__>проект вроде и не делает ничего, в одного написать можно — ф-ти немного, а классов-классов-то, а каждому классу еще и по интерфейсу. файлов вагоны — вообще ничего не найдешь. каждый класс че-то делегирует и переадресует, потом сериализует, десериализует и опять делегирует и переадресует. и никто ничего не делает. только куда-то там инверсит контроль, абстрагирует и делегирует.
Смотрел я тут прокет дома один, вроде ничего и не делает, а одних материалов навезли уже два вагона, тут кран ставят, там электростанцию, а эти вообще зачем-то канализацию роют и все при деле и все заняты, а дом-то, дом-то где? Вторую неделю строят.
Здравствуйте, __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-классов тоже пишете?
я из той "когорты" что пишет не для себя, а для других. мне жалко время людей, которым приходится разбираться в моем коде. поэтому код должен быть прост и минимален.
Re[4]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Vzhyk, Вы писали: V>>Нет ты не прав. А всегда пишу UT для себя. __>кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство. могу напомнить про эксперимент с обезьянами, которых водой обливали
А был ли такой эксперимент на самом деле, или это тоже социальный вариант опровержения "социального доказательства"?
__>вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний, где усатых разработчиков в сандалях нужно жестко пороть, чтобы они херню не делали. и то ведь умудряются. возможно, там они чем-то помогают. но если смотреть с позиции разумного, доброго и светлого, пока что ни одного довода, обьясняющего причину использования юнит-тестов названо не было.
Верная мысль — UT нужны для разработчиков, чтобы они думали головой перед тем как писать код. Еще, говорят, UT помогают регрессионные баги ловить, но при частых изменениях поддержка UT оказывается дороже, чем профит от ловли багов.
Re[4]: Проектирование системы с учетом юнит-тестирования
On 22.12.2012 19:03, gandjustas wrote:
> Верная мысль — UT нужны для разработчиков, чтобы они думали головой > перед тем как писать код. Еще, говорят, UT помогают регрессионные баги > ловить, но при частых изменениях поддержка UT оказывается дороже, чем > профит от ловли багов.
Конечно. И на этом фоне очень прикольно смотрятся конторы, которые
пытаются осуществлять 100% покрытие кода юнит тестами. Прямо как из
известной пословицы: "Заставь дурака богу молиться — он себе лоб расшибет".
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, landerhigh, Вы писали: L>Хочешь конкретики — перестань выдавать свои фантазии за непреложную истину.
я понять все не могу — конкретика по этому вопросу это какой-то такой большой бизнес-секрет? и для его узнавания я должен покаяться в чем-то и поунижаться перед кем-то?
моего опыта для меня достаточно чтобы сделать определенные выводы насчет юнит-тестов. единственная причина по которой нет конкретики по вопросу хоть какой-то пользы от них так это потому что и сказать-то нечего. тут уж к бабке не ходи. никто ничего сказать не может. ну а фантазии оно тоже хорошо. помню, был у нас пацан один в классе, так тот каждый день по словам его ездил на танке и стрелял дома из гранатомета.
говорить, что "знаю, да не скажу, потому что ты плохой" это тема примерно так 5ого класса школы.
Re[5]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, landerhigh, Вы писали: L>Здравствуйте, __kot2, Вы писали: __>>вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний, L> L>Хочешь конкретики — перестань выдавать свои фантазии за непреложную истину.
и, кстати, товарищам, не сильно осиливших или подзабывших русский язык, напоминаю, что выражение "я так понимаю" использованное мной, указывает на личное мнение, а не на непреложную истину
Re[4]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Vzhyk, Вы писали: V>>Нет ты не прав. А всегда пишу UT для себя. __>кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство. могу напомнить про эксперимент с обезьянами, которых водой обливали
В моей собственной практике они несколько раз отловили баги.
Плюс они помогают разрабатывать/обтачивать интерфейс.
Потому что вот ты пишешь компонент А, потом видишь, что из него можно выделить компонент Б поменьше — и выделяешь, и вроде все нормально, за исключением того, что у Б получается ровно один юзер и таким образом можно особо интерфейс Б не продумывать — два компонента всегда договорятся.
А вот если ты начинаешь творчески писать юнит-тесты для Б, проверяя его работу в разнообразных ситуациях (ты это и так должен делать, по-хорошему, просто теперь ты это все заодно оформляешь в виде теста, который в любой момент можно прогнать и убедиться в правильности работы компонента), то сразу становятся видны косяки интерфейса и он выправляется и компонентос становится гораздо удобнее пользоваться и увеличивается вероятность, что ты его заюзаешь в другой части проекта. Потому что эти юнит-тесты сильно увеличивают число сценариев использования Б, по сравнению с единственным первоначальным.
Но, естественно, если отнестись к написанию юнит-тестов формально, то они смогут только внесенные баги ловить.
Почему удобнее оформлять варианты использования в виде теста? Просто потому, что это итеративный процесс. Ты начинаешь обтачивать компонент в сценарии, который у тебя есть сразу, по факту создания этого компонента. Потом ты добавляешь еще штук пять сценариев, все работает, ты всем доволен. А потом ты добавляешь шестой и понимаешь, что в определенном месте косяк, и из-за этого этот шестой сценарий крайне неудобен, и понимаешь, как именно надо изменить интерфейс ил реализацию. Но после этого изменения тебе ведь надо убедиться, что не сломались первоначальные 6 сценариев, так? Если ты из сразу записал в виде тестов, с этим никаких проблем нет. Плюс, если для нового сценария нужно поменять интерфейс компонента, ты сразу увидишь, как это изменение влияет на остальные сценарии (потому что они перестали компилироваться), и сможешь принять адекватное решение — не будет ли твое изменение слишком дорогим, или надо подойти к проблеме несколько с другой стороны, чтоб удовлетворить всем сценариям.
Автоматизация в виде юнит-тестов в этом деле очень помогает.
Здравствуйте, jazzer, Вы писали:
J>А вот если ты начинаешь творчески писать юнит-тесты для Б, проверяя его работу в разнообразных ситуациях (ты это и так должен делать, по-хорошему, просто теперь ты это все заодно оформляешь в виде теста, который в любой момент можно прогнать и убедиться в правильности работы компонента), то сразу становятся видны косяки интерфейса и он выправляется и компонентос становится гораздо удобнее пользоваться и увеличивается вероятность, что ты его заюзаешь в другой части проекта. Потому что эти юнит-тесты сильно увеличивают число сценариев использования Б, по сравнению с единственным первоначальным.
На моей практике все ровно наоборот. Оттачиваешь Б, делаешь из него совершенный звездолет... а в итоге он нигде кроме А больше не пригодился. Но это фигня. Ты получил моральное удовольствие от того, что создал такую классную штуку. Полученное удовольствие компенсирует потраченное время.
Хуже когда обнаруживается, что звездолет должен еще под водой плавать и ты встаешь перед делемой: переделать звездолет так, чтобы он остался таким же совершенным и научился плавать под водой (40 часов), прикрутить к звездолету винт и написать ТУДУ комент "вернуть совершенство" (2 часа) или выкинуть нафик ненужные функции звездолета и потом уже сделать хорошую летающую подлодку из нее (8 часов).
Что же делать??? 40 часов не всегда есть, да и желания делать совершенство уже нет -- ты ведь примерно то же самое уже делал. 2 выбирается только если завтра релиз. А 3), третий вариант, ИХМО, настолько сильно врезается в память, что желание делать звездолеты в будущем поубавится. Во всяком случае, это справедливо для меня
ИХМО, пусть Б так и останется неизвестным героем. Тогда в будущем не будет сильно больно с ним расставаться
J>Если ты из сразу записал в виде тестов, с этим никаких проблем нет. Плюс, если для нового сценария нужно поменять интерфейс компонента, ты сразу увидишь, как это изменение влияет на остальные сценарии (потому что они перестали компилироваться), и сможешь принять адекватное решение — не будет ли твое изменение слишком дорогим, или надо подойти к проблеме несколько с другой стороны, чтоб удовлетворить всем сценариям. J>Автоматизация в виде юнит-тестов в этом деле очень помогает.
А вот надо ли это все в повседневной жизни разработке? Дой опыт говорит, что для 90% компонент не нужно совершенно.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[4]: Проектирование системы с учетом юнит-тестирования
Как дети малые... Обе стороны.
__>вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний, где усатых разработчиков в сандалях нужно жестко пороть, чтобы они херню не делали.
Модульные тесты пришли из динамических языков, как средство борьбы с рантайм-ошибками, которые в статически типизированных языках вылавливает компилятор. На практике оказалось, что и для статических языков это весьма полезная штука, если применять без фанатизма.
По поводу удачных примеров — есть видео дядьки с ником kzu (Daniel Cazzulino), автора moq и ряда других полезных библиотек и тулов. В этом видео он пишет IoC контейнер, но с применением TDD на реальном боевом проекте. То есть основная идея этого видео не TDD, а IoC контейнер, но в ходе этого видео очень хорошо видно как использовать тесты на практике в реальных проектах. Ничего лишнего, все по делу — никаких лишних интерфейсов, публичных методов и прочих приседаний исключительно в угоду TDD. Я вообще не большой фанат подобного рода подачи материала, но в данном случае меня поразило, что когда мне понадобилось реализовать свой контейнер, то я пришел к очень похожим результатам и без TDD, еще до того как на это видео наткнулся, только усилий чуть больше потратить пришлось. http://blogs.clariusconsulting.net/kzu/funq-screencast-series-on-how-to-building-a-di-container-using-tdd/
Мы уже победили, просто это еще не так заметно...
Re[6]: Проектирование системы с учетом юнит-тестирования
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>А вот если ты начинаешь творчески писать юнит-тесты для Б, проверяя его работу в разнообразных ситуациях (ты это и так должен делать, по-хорошему, просто теперь ты это все заодно оформляешь в виде теста, который в любой момент можно прогнать и убедиться в правильности работы компонента), то сразу становятся видны косяки интерфейса и он выправляется и компонентос становится гораздо удобнее пользоваться и увеличивается вероятность, что ты его заюзаешь в другой части проекта. Потому что эти юнит-тесты сильно увеличивают число сценариев использования Б, по сравнению с единственным первоначальным. A>На моей практике все ровно наоборот.
Ну, у каждого своя практика
A>Оттачиваешь Б, делаешь из него совершенный звездолет... а в итоге он нигде кроме А больше не пригодился. Но это фигня. Ты получил моральное удовольствие от того, что создал такую классную штуку. Полученное удовольствие компенсирует потраченное время. A>Хуже когда обнаруживается, что звездолет должен еще под водой плавать и ты встаешь перед делемой: переделать звездолет так, чтобы он остался таким же совершенным и научился плавать под водой (40 часов), прикрутить к звездолету винт и написать ТУДУ комент "вернуть совершенство" (2 часа) или выкинуть нафик ненужные функции звездолета и потом уже сделать хорошую летающую подлодку из нее (8 часов). A>Что же делать??? 40 часов не всегда есть, да и желания делать совершенство уже нет -- ты ведь примерно то же самое уже делал. 2 выбирается только если завтра релиз. А 3), третий вариант, ИХМО, настолько сильно врезается в память, что желание делать звездолеты в будущем поубавится. Во всяком случае, это справедливо для меня
Во-первых, здравый смысл никто не отменял (про звездолеты).
Во-вторых, к религиозно-фанатичному следованию TDD тоже никто никого не принуждает (про дилеммы).
Ну и в-третьих, таки нормально сделанный звездолет (который летает сам по себе, а не только в составе всей системы с базой данных) гораздо проще превратить в лодку (при помощи рефакторинга, правильность которого (сюрприз!) автоматически контролируется уже имеющимися тестами), чем самолет, вцементированный в остальную систему с уходящими неизвестно куда проводами — потому что ты понятия не имеешь, как отзовется то или иное изменение, ибо юнит-тест на такое написать невозможно, а регрессионный тест становится тестом всей системы, с экспоненциально маленьким покрытием, ессно.
Искусство инженера состоит в балансировании на стыке подходов/технологий, а совсем не в слепом применении одного и того же, будь то что угодно или что-либо еще.
J>>Если ты из сразу записал в виде тестов, с этим никаких проблем нет. Плюс, если для нового сценария нужно поменять интерфейс компонента, ты сразу увидишь, как это изменение влияет на остальные сценарии (потому что они перестали компилироваться), и сможешь принять адекватное решение — не будет ли твое изменение слишком дорогим, или надо подойти к проблеме несколько с другой стороны, чтоб удовлетворить всем сценариям. J>>Автоматизация в виде юнит-тестов в этом деле очень помогает. A>А вот надо ли это все в повседневной жизни разработке? Дой опыт говорит, что для 90% компонент не нужно совершенно.
А мой говорит — нужно. Потому что, например, у нас в какой-то момент оказалось, что многие компоненты неплохо бы высунуть в Питон и дергать оттуда — и внезапно оказалось, что развязанные благодаря TDD интерфейсы очень сильно облегчили эту задачу.
И затраченное "тогда" время на изолирование компонента и продумывание его интерфейса (облегченное тестами) окупилось сейчас сторицей.
A>СУВ, Aikin
Мы уже победили, просто это еще не так заметно...
