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

__>Здравствуйте, Vzhyk, Вы писали:
V>>Нет ты не прав. А всегда пишу UT для себя.
__>кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство. могу напомнить про эксперимент с обезьянами, которых водой обливали
А был ли такой эксперимент на самом деле, или это тоже социальный вариант опровержения "социального доказательства"?

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

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

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



Хочешь конкретики — перестань выдавать свои фантазии за непреложную истину.

On 22.12.2012 19:03, gandjustas wrote:

> Верная мысль — UT нужны для разработчиков, чтобы они думали головой
> перед тем как писать код. Еще, говорят, UT помогают регрессионные баги
> ловить, но при частых изменениях поддержка UT оказывается дороже, чем
> профит от ловли багов.
Конечно. И на этом фоне очень прикольно смотрятся конторы, которые
пытаются осуществлять 100% покрытие кода юнит тестами. Прямо как из
известной пословицы: "Заставь дурака богу молиться — он себе лоб расшибет".

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

говорить, что "знаю, да не скажу, потому что ты плохой" это тема примерно так 5ого класса школы.

Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, __kot2, Вы писали:
__>>вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний,
L>
L>Хочешь конкретики — перестань выдавать свои фантазии за непреложную истину.
и, кстати, товарищам, не сильно осиливших или подзабывших русский язык, напоминаю, что выражение "я так понимаю" использованное мной, указывает на личное мнение, а не на непреложную истину

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

__>Здравствуйте, Vzhyk, Вы писали:
V>>Нет ты не прав. А всегда пишу UT для себя.
__>кроме социального доказательства пока никто не сказал, зачем тесты эти нужны. "здесь так принято" и "все так делают" это не доказательство. могу напомнить про эксперимент с обезьянами, которых водой обливали

В моей собственной практике они несколько раз отловили баги.

Плюс они помогают разрабатывать/обтачивать интерфейс.
Потому что вот ты пишешь компонент А, потом видишь, что из него можно выделить компонент Б поменьше — и выделяешь, и вроде все нормально, за исключением того, что у Б получается ровно один юзер и таким образом можно особо интерфейс Б не продумывать — два компонента всегда договорятся.

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

Но, естественно, если отнестись к написанию юнит-тестов формально, то они смогут только внесенные баги ловить.


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

You will always get what you always got
  If you always do  what you always did

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

J>А вот если ты начинаешь творчески писать юнит-тесты для Б, проверяя его работу в разнообразных ситуациях (ты это и так должен делать, по-хорошему, просто теперь ты это все заодно оформляешь в виде теста, который в любой момент можно прогнать и убедиться в правильности работы компонента), то сразу становятся видны косяки интерфейса и он выправляется и компонентос становится гораздо удобнее пользоваться и увеличивается вероятность, что ты его заюзаешь в другой части проекта. Потому что эти юнит-тесты сильно увеличивают число сценариев использования Б, по сравнению с единственным первоначальным.
На моей практике все ровно наоборот. Оттачиваешь Б, делаешь из него совершенный звездолет... а в итоге он нигде кроме А больше не пригодился. Но это фигня. Ты получил моральное удовольствие от того, что создал такую классную штуку. Полученное удовольствие компенсирует потраченное время.
Хуже когда обнаруживается, что звездолет должен еще под водой плавать и ты встаешь перед делемой: переделать звездолет так, чтобы он остался таким же совершенным и научился плавать под водой (40 часов), прикрутить к звездолету винт и написать ТУДУ комент "вернуть совершенство" (2 часа) или выкинуть нафик ненужные функции звездолета и потом уже сделать хорошую летающую подлодку из нее (8 часов).
Что же делать??? 40 часов не всегда есть, да и желания делать совершенство уже нет -- ты ведь примерно то же самое уже делал. 2 выбирается только если завтра релиз. А 3), третий вариант, ИХМО, настолько сильно врезается в память, что желание делать звездолеты в будущем поубавится. Во всяком случае, это справедливо для меня

ИХМО, пусть Б так и останется неизвестным героем. Тогда в будущем не будет сильно больно с ним расставаться


J>Если ты из сразу записал в виде тестов, с этим никаких проблем нет. Плюс, если для нового сценария нужно поменять интерфейс компонента, ты сразу увидишь, как это изменение влияет на остальные сценарии (потому что они перестали компилироваться), и сможешь принять адекватное решение — не будет ли твое изменение слишком дорогим, или надо подойти к проблеме несколько с другой стороны, чтоб удовлетворить всем сценариям.
J>Автоматизация в виде юнит-тестов в этом деле очень помогает.
А вот надо ли это все в повседневной жизни разработке? Дой опыт говорит, что для 90% компонент не нужно совершенно.

СУВ, Aikin

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

Как дети малые... Обе стороны.

__>вообще, я так понимаю, юнит-тесты пришли из веба, из больших компаний, где усатых разработчиков в сандалях нужно жестко пороть, чтобы они херню не делали.
Модульные тесты пришли из динамических языков, как средство борьбы с рантайм-ошибками, которые в статически типизированных языках вылавливает компилятор. На практике оказалось, что и для статических языков это весьма полезная штука, если применять без фанатизма.
По поводу удачных примеров — есть видео дядьки с ником 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/

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

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

J>>А вот если ты начинаешь творчески писать юнит-тесты для Б, проверяя его работу в разнообразных ситуациях (ты это и так должен делать, по-хорошему, просто теперь ты это все заодно оформляешь в виде теста, который в любой момент можно прогнать и убедиться в правильности работы компонента), то сразу становятся видны косяки интерфейса и он выправляется и компонентос становится гораздо удобнее пользоваться и увеличивается вероятность, что ты его заюзаешь в другой части проекта. Потому что эти юнит-тесты сильно увеличивают число сценариев использования Б, по сравнению с единственным первоначальным.
A>На моей практике все ровно наоборот.
Ну, у каждого своя практика

A>Оттачиваешь Б, делаешь из него совершенный звездолет... а в итоге он нигде кроме А больше не пригодился. Но это фигня. Ты получил моральное удовольствие от того, что создал такую классную штуку. Полученное удовольствие компенсирует потраченное время.
A>Хуже когда обнаруживается, что звездолет должен еще под водой плавать и ты встаешь перед делемой: переделать звездолет так, чтобы он остался таким же совершенным и научился плавать под водой (40 часов), прикрутить к звездолету винт и написать ТУДУ комент "вернуть совершенство" (2 часа) или выкинуть нафик ненужные функции звездолета и потом уже сделать хорошую летающую подлодку из нее (8 часов).
A>Что же делать??? 40 часов не всегда есть, да и желания делать совершенство уже нет -- ты ведь примерно то же самое уже делал. 2 выбирается только если завтра релиз. А 3), третий вариант, ИХМО, настолько сильно врезается в память, что желание делать звездолеты в будущем поубавится. Во всяком случае, это справедливо для меня

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

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

J>>Если ты из сразу записал в виде тестов, с этим никаких проблем нет. Плюс, если для нового сценария нужно поменять интерфейс компонента, ты сразу увидишь, как это изменение влияет на остальные сценарии (потому что они перестали компилироваться), и сможешь принять адекватное решение — не будет ли твое изменение слишком дорогим, или надо подойти к проблеме несколько с другой стороны, чтоб удовлетворить всем сценариям.
J>>Автоматизация в виде юнит-тестов в этом деле очень помогает.
A>А вот надо ли это все в повседневной жизни разработке? Дой опыт говорит, что для 90% компонент не нужно совершенно.

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

A>СУВ, Aikin

You will always get what you always got
  If you always do  what you always did