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

XSH>Здравствуйте, тёзка
XSH>Вы писали:

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

XSH>Дубль 3: Я не против тестов . Я за тесты как таковые. Почти все аргументы за TDD приведённые мне выглядят примерно так:
XSH>"тесты — это хорошо потому-то и потому-то, поэтому надо тестировать!". Это я и сам знаю. Я и сам люблю "продолжать с хорошим настроением".
XSH>Но я не могу писать тесты ДО. Это коряво! Это идет в разрез с образом моего мышления. Это не поддерживает моя среда разработки, наконец!

Хочется задать вопрос — а зачем ты сознательно так себя ограничиваешь? Эти фразы "не могу", "это коряво", "вразрез" являются не чем иным, как клеткой, добровольно установленной в собственном сознании.

Сбрось оковы, скажи себе "у меня обязательно получится", и ты удивишься насколько хорошо TDD может заработать и для тебя.

Вспоминается: лучшим оружием в руках угнетателя является сознание угнетенного.

--

Владимир.

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

XSH>Здравствуйте, тёзка
XSH>Вы писали:

XSH>В предыдущем посте Вы высказали то мнение, высказывания которого я ждал с самого начала дискуссии:
XSH>Тест — это еще и испытание удобности изобретаемого интерфейса класса.
XSH>За это тебе и "+".
сенксь
XSH>На мой взгляд это единственная разумная причина, по которой тесты следует писать ДО.
XSH>Другое дело, что это немножко другие тесты: тесты интерфейса. И они вовсе не обязаны быть автоматическими. Их бессмыслено включать в unit-test-ы. Они в принципе могут не исполняться. Эти тесты (тестирование удобности интерфейса) я действительно пишу ДО написания кода, но я это делаю карандашиком на листочке бумаги формата А4!
Это хорошо, я тоже так делаю, но и раньше так делал до TDD, и получал результат, но немного больше времени уходило на полет мысли и обдумываение ситуаций и возможностей, которые собственно никому потом не нужны были, разве что мне, дабы насладиться самим процессом проектирования, в результате чего сроки на реализацию моего полета мысли выростали очень сильно. А еще обидней было, когда тем что напридумывал пользоваться не удобно, или процентов 40 ненужного или неиспользуемого кода. Это как раз то, за что плюс Это первое.

Второе. Сегодня мне босс сказал сделать "вот так", я написал определенное количество тестиков из слов босса плюс моя обрботка по случаю граничных условий и очень быстро выдал результат и я и босс довольны. Могу даже сразу не бежать к боссу и говорить, что все сделано, а продолжить наслаждаться улучшением кода, подчисткой и т.д. (то что называют рефакторингом и при этом постоянно уверен, что то, что работало раньше, работает и сейчас, а если на работает, то я что-то поломал и мне легко найти то, что я поломал, так как после малейшего изменения запустил тест и все, я могу либо откатится на те 5 минут назад либо сразу же подправить. Скороссть возрастает, наслаждение получаю и я и босс. Босс говорит, а не поменять ли нам вот так, поскольку неудобно как-то получилось, юзеры жалуются. Я сразу не вдумываесь в то, как я это сделаю, говорю, ок, "любой каприз за ваши деньги" и бегу писать тесты, и тесты только для того что собственно меняется, я не боюсь этого делать, так как все остальное не розвалиться, оно под контролем целой серии тестов.

И еще третье. Еще TDD я оценил, когда жизнь заставила писать на PHP, язык то скриптовый, не типизированый и исполнитель обнаружит, что не передан нужный параметр или вызван несуществующий метод, только когда добереться до этого места. А тесты сразу просекут эти моменты. И сейчас я забыл вообще про такие ошибки. И мне уже не становиться стыдно за мои глупые ошибки , которые у каждого бывают, ведь все мы люди.

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

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

Это, на первый взгляд, все
Конечно же, не все так красочно как кажется, иногда бывают стрессы, когда говорят что-то сделать сию же минуту и по старинке начинаешь с написания кода, о чем потом очень и искренне жалею, но не всегда могу себя остановить Может это потому, что процесс действительно неестественный, а может потому, к чему я больше склоняюсь, что неправильно или не так нас учили изначально и если изначально учить так, то этот процесс и будет естественным, а наоборот, как раз и будет неестественно и неправильно

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

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


XSH>ёпрст. Я же специально в одном из своих постов сказал что я НЕ ПРОТИВ тестирования! Я ЗА тестирование. Но писать тесты перед написанием тестируемого кода — это противоречит работе нормального программистского мозга. Мозг мыслит абстрактными вещами, а тесты — конкретными примерами. Мозг прибегает к конкретным примерам, только в исключительных ситуациях — когда абстрактно не получается мыслить. А TDD навязывает именно способ мышления use-case-ами!

Поддерживаю. Как всегда, есть и исключения, когда мыслить use-casaми оказывается более продуктивным. Но это далеко не панацея, имхо.

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

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

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

hrg>>Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как
hrg>>правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую
hrg>>електроникой грань, все встанет на свои места

AJ>То есть получается — если уже начал писать программу без ТДД, то все, поезд
AJ>ушел?

Не совсем.
Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения.
Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.

AJ>В принципе вопрос не отменяется — можно ведь и с нуля писать прогу, которую будет очень трудно протестировать.

А то ж.

AJ>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?

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

--

Владимир.

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


X>> А я всегда считал, что от перемены мест слагаемых сумма не
X>> меняется...
X>> Объем кода теста, имхо, не очень зависит от того, когда я его буду
X>> писать — до или после написания тестируемого кода.

X>> То, что предлагается — по сути размазать написание тестов по всему
X>> процессу создания программы — на мой скромный взгляд, является всего
X>> лишь неким психологическим самообманом

hrg>Ну как тебе сказать. В традиционном понимании мы начинаем писать прогу, в
hrg>уме представляя, что она должна делать. А тут ты сначала пишешь, что на
hrg>должна делать (можно прям сценарий из use-case'a выдирать), а потом пишешь
hrg>реализацию этого.

Лично я, когда начинаю прогу писать, не use-case-ами мыслю. Это только если совсем тяжко и туго — на примерах разбираю, что и как должно быть. А в основном пытаюсь мыслить максимально абстрактно. Таким вот образом TDD и вступает в противоречие с моим ходом мыслей (и не только с моим, на сколько я знаю). В том смысле, что любой тест — это по сути, как уже было отмечено выше, проверка работы на каком-то конкретном примере (use-case), а мыслю я далеко не конкретными примерами.

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

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

hrg>Тут тоже есть свои причины. Можно долго и пространно объяснять, что, почему,
hrg>как, по какой причине, а можно просто сказать: "Будешь делать не так,
hrg>убунах".

Немогу не согласится. Вот только нужно быть 1000 раз увереным в своей правоте перед тем как произносить такие фразы с бубнами.

ПЛ>>> Я думаю при таком подходе поднимается вопрос "А что же на самом
ПЛ>>> деле я хочу сделать/достичь?"

X>> ... это прямо как заклинания, вводящие новичка в транс, чтобы он
X>> поверил в то, что сумма от перемены мест слагаемых таки изменится

hrg>т.е. для тебя важнее процесс, чем резальтат?

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


hrg> Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Nemiroff борет]

XopoSHiy -> "Re[4]: Test Driven Development — только для простеньких клас" :

X> Лично я, когда начинаю прогу писать, не use-case-ами мыслю. Это
X> только если совсем тяжко и туго — на примерах разбираю, что и как
X> должно быть. А в основном пытаюсь мыслить максимально абстрактно.
X> Таким вот образом TDD и вступает в противоречие с моим ходом мыслей
X> (и не только с моим, на сколько я знаю). В том смысле, что любой тест
X> — это по сути, как уже было отмечено выше, проверка работы на
X> каком-то конкретном примере (use-case), а мыслю я далеко не
X> конкретными примерами.

Хм...ты программу для заказчика или для себя пишешь? Ты же не будешь
объяснять заказчику, что с точки зрения максимальной абстракции прогамма
безупречна? Я вот беру ТЗ и говорю — видишь эту фичу? Работает? Как надо?
(чо не так? — сам ТЗ подписывал ). Подписывай акт сдачи-приемки

X> А по скольку я искренне уверен, чно нормальный программист должен
X> мыслить именно так как я, то и считаю TDD неадекватной методой....
X> Не в том смысле, что тестировать не надо, а в том смылсе, что тесты
X> не являются первичными при разработке Это неестественно.

У меня вначале тоже ломка была

Yury Kopyl aka hrg | http://id.totem.ru | Гордость мешает доходам!

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

_>Это уже integration testing. А как ты помнишь, TDD включает в себя только unit-testing. Но с другой стороны при обнаружении бага ты можешь написать integration test на него, чтобы он больше не возникал.

Лично я поступаю несколько иначе. У меня как правило одни модули используют другие, одни классы строятся на основании других классов. Если я разрабатываю что-то снизу вверх, то я сначала пишу тесты для отдельных классов, потом для класса, который их использует. Если я разрвбатываю сверху вниз (так бывает чаще всего), то сначала я пишу тест для бОльшего класса, часто при этом применяя вместо составляющих его частей Mock-объекты, а затем уже тесты для каждого из мелких объектов и сами объекты.
Так что, строго говоря, можно и интеграционные тесты писать в рамках этой идеологии.


_>И вообще-то, по большому счету, тестирование в TDD не самое важное. Самое важное это Test-First Design, т.е. дизайн, рождающийся благодаря априорному наличию требований, выраженных в коде.

_>Но так удачно получилось, что требования и unit-testing реализованы в одном лице (в виде unit-тестов). Собственно от тестов с точки зрения именно тестирования требуется лишь хорошее покрытие кода с тем, чтобы без боязни применять refactoring. Который в свою очередь является механизмом поддержки evolutionary design, и если копнуть дальше, то и самого ООП...

Хм... это вообще говоря сомнительный вопрос.
1) В большинстве случаев в коде невозможно выразить ВСЕ требования, так же как и невозможно протестировать ВСЕ.Это утопия. Однако, лучше протестировать хоть что-то, чем ничего. TDD, кстати, вовсе не подразумевает ПОЛНОГО набора тестов, который ТЕСТИРУЕТ ВСЕ. Подразумевается, что тестируется основная функциональность, а при необходимости (например, найден новый баг или например сегодня мне в голову пришла новая идея) набор тестов пополняется.
2) Требования, реализованные в коде трудно читать и изменять, поэтому вряд-ли код можно расценивать как способ выражения требований. А уж если очень хочется — обратитесь к формальным языкам описания требований, таким как RSL



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

При разработке какой-либо задачи удобно бывает смотреть на нее с разных сторон. Я считаю, что задачу решить тем проще, чем она понятней, а она тем понятней, чем с большего числа сторон рассмотрена. TDD предоставляет нам еще один взгляд на задачу — с чисто функциональной точки зрения.
Когда Вы пишете обычный код, вы, как правило, отвечаете на вопрос КАК что-то должно быть сделано. Когда Вы пишете тесты — вы отвечаете на вопрос ЧТО КОНКРЕТНО должно быть сделано.
Полностью ответить на первый вопрос — означает создать полностью работающий программный продукт.
Полностью ответить на второй вопрос — как не странно, тоже означает создать полностью работающий программный продукт!!! Посмотрите, хотя бы на язык Пролог и парадигму программирования ограничениями. Ведь они именно что и делают — описывают ЧТО ИМЕННО должна делать программа, совершенно не заботясь о том, КАК !

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

Чаще всего я разрабатываю программы сверху вниз и тестирую вначале, а потом пишу код. Но иногда я делаю в точности наоборот, если это позволяет мне легче разобраться в том, что я делаю. Однако, в любом случае, тесты я пишу, и не раз оценил уже пользу тестов для поддержания разработки. Некоторые тесты тянутся у меня из версии в версию очень подолгу, когда код давно уже 15 раз переписан и частично выброшен.

Итак, разрабатывайте тесты, отвечая на вопрос, что именно нужно сделать. Пишите программы, отвечая на вопрос КАК именно нужно это сделать. Разрабатывайте куски задачи сверху вниз для того, чтобы четко видеть архитектуру. Разрабатывайте другие куски снизу вверх, если архитектура проблемы чересчур необъятна. Пробуйте, пытайтейсь, главное, не зацикливайтесь на каком-то одном способе в ущерб другим.

A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :

A> Здравствуйте, Павел Леонов, Вы писали:

A> Так получается, тесты проверяют лишь минимальную функциональность.

(поперла философия Тесты проверяют только то, что ты написал. Тесты не
явлются мыслящим существом и тем более не обладают телепатическим даром.
Тесты не увеличивают радиус кривизны рук

A> Типа, "по крайней мере в одном случае (чаще всего простейшем) оно
A> работает!"

Напиши граничные тесты, там где этот случай работать не должен.

A> Ну тогда не надо называть это тестами. Менее бы вводило в заблуждение
A> что-нибудь вроде "иллюстрации простейшего использования"

Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...

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


XSH>А я всегда считал, что от перемены мест слагаемых сумма не меняется...
XSH>Объем кода теста, имхо, не очень зависит от того, когда я его буду писать — до или после написания тестируемого кода.

XSH>То, что предлагается — по сути размазать написание тестов по всему процессу создания программы — на мой скромный взгляд, является всего лишь неким психологическим самообманом
Лучше иметь психологический обман, чем не иметь не чего.

}{орошо. Попробую привести один маленький пример, почему тесты лучше писать по всему процессу создания программы.
Есть у нас Use-Case, называется "Создание пользователя", предположим, что в системе есть класс "User". Выполнение этого прецедента будет вызов метода Create() у объекта класса User. Наша задача по коду проинициализировать поля объекта и вызвать Create().
Что может быть проще, зачем проверять и так все ясно, реализация прецедента компилируется и славу богу!!! Но постойте, теперь что бы мне проверить прецедент надо перейти в GUI или WEB, написать код подключения объекта к контролам, написать обработчики событий…. Запустить приложение и увидеть что ….. не работает. Ошибка в хранимой процедуре.... или... не хватает прав..., ну как же.. .бывает подправляем в коде, настраиваем права... отлично, все работает, ура едем дальше. ....

прошло полтора месяца...

Надо подкрутить хранимую процедуру которая используется при импорте данных! Сейчас подкрутим.. подкрутили... А кто еще в системе работает с ней... Кажется создание пользователя. Мне еще пол часа, посмотреть все ли у нас на месте.

,а теперь вопрос, почему нельзя было сделать в самом начале тест на создание пользователя?! Код написанный в GUI и WEB перенести в тест и в любой момент мы можем его запустить и посмотреть как работает функция создания пользователя, не запускать GUI или WEB, а запустить тест и понять кто плохой, наш прецедент сломался или все хорошо.
Посмотрим по времени сколько это может занять... могу заявить авторитетно создание теста займет, 2 минуты. Мое резюме. Заплатить 2 минуты что бы спать спокойно, оно того стоит.

A.J. -> "Test Driven Development — только для простеньких классов?" :

A> Просто надоело — пишутся тесты только для "написанных с нуля"
A> простеньких собственных классов — а про то, как действительно важные
A> вещи протестировать — нигде не слова. Интересно, может ли быть
A> сформулировано правило, по которому можно протестировать практически
A> любой кусок программы?

Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как
правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую
електроникой грань, все встанет на свои места

A> Реакции типа "да ты нифига не понял в этой жизни" принимаются тоже,
A> при наличии аргументации

Yury Kopyl aka hrg | http://id.totem.ru |
"Хоббиты-маздай! Мордовия-фарева!" (С)Сарумян

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

ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.

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

То, что предлагается — по сути размазать написание тестов по всему процессу создания программы — на мой скромный взгляд, является всего лишь неким психологическим самообманом

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

ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?"

... это прямо как заклинания, вводящие новичка в транс, чтобы он поверил в то, что сумма от перемены мест слагаемых таки изменится

XopoSHiy -> "Re[2]: Test Driven Development — только для простеньких клас" :

X> Здравствуйте, Павел Леонов, Вы писали:

ПЛ>> Я думаю при таком подходе поднимается вопрос "А что же на самом
ПЛ>> деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну
ПЛ>> типа пусть там все будет все круто". Поэтому очередной тест
ПЛ>> наверное стоит рассматривать как этап достяжения цели, а не как
ПЛ>> некий антивирус, мол "Что нибудь да поймает". Во втором случае
ПЛ>> получиться "Пойди туда не заню куда...", крыша съедет составлять
ПЛ>> их.

X> А я всегда считал, что от перемены мест слагаемых сумма не
X> меняется...
X> Объем кода теста, имхо, не очень зависит от того, когда я его буду
X> писать — до или после написания тестируемого кода.

X> То, что предлагается — по сути размазать написание тестов по всему
X> процессу создания программы — на мой скромный взгляд, является всего
X> лишь неким психологическим самообманом

Ну как тебе сказать. В традиционном понимании мы начинаем писать прогу, в
уме представляя, что она должна делать. А тут ты сначала пишешь, что на
должна делать (можно прям сценарий из use-case'a выдирать), а потом пишешь
реализацию этого.

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

Тут тоже есть свои причины. Можно долго и пространно объяснять, что, почему,
как, по какой причине, а можно просто сказать: "Будешь делать не так,
убунах".

ПЛ>> Я думаю при таком подходе поднимается вопрос "А что же на самом
ПЛ>> деле я хочу сделать/достичь?"

X> ... это прямо как заклинания, вводящие новичка в транс, чтобы он
X> поверил в то, что сумма от перемены мест слагаемых таки изменится

т.е. для тебя важнее процесс, чем резальтат?

Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Nemiroff борет]

Может тут есть что интересного:

http://weblogs.asp.net/wallen/

Practical Testing
Len Holgate is writing a series of posts on Unit Testing with a non-trivial example. Good stuff, check it out.

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

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

Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.

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

ПЛ>>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.

XSH>А я всегда считал, что от перемены мест слагаемых сумма не меняется...
XSH>Объем кода теста, имхо, не очень зависит от того, когда я его буду писать — до или после написания тестируемого кода.
XSH>То, что предлагается — по сути размазать написание тестов по всему процессу создания программы — на мой скромный взгляд, является всего лишь неким психологическим самообманом
Не согласен. Если руки не дошли сразу написать тестик, позднее они не дойдут тем более.

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

XSH>А я всегда считал, что от перемены мест слагаемых сумма не меняется...
XSH>Объем кода теста, имхо, не очень зависит от того, когда я его буду писать — до или после написания тестируемого кода.
В даном случае это совсем не слагаемые, поскольку результат может получиться совсем другой, если сначала требования в коде, а потом сам код, реализующий требования, на собственном опыте с удивлением начал это замечать .

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

XSH>А тот ворох религиозно-политико-идеологических фраз, который заставляют заучивать всех новичков, например
ПЛ>>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?"
XSH>... это прямо как заклинания, вводящие новичка в транс, чтобы он поверил в то, что сумма от перемены мест слагаемых таки изменится
Таки меняется, я как раз, это на себе ощутил. Получается, что я стал писать только то, что "действительно нужно", а не то, что "может быть понадобиться". И, соответственно, слагаемые и результат изменились
Это мое мнение, мой опыт.

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

XSH>Но я не могу писать тесты ДО. Это коряво! Это идет в разрез с образом моего мышления. Это не поддерживает моя среда разработки, наконец!
XSH>Я пишу тесты. Но я это делаю ПОСЛЕ напиания кода.

Как я писал уже здесь:
http://www.rsdn.ru/Forum/Message.aspx?mid=821923&only=1

Автор: borisman2
Дата: 23.09.04

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

Тестировать сначала, а потом писать код и правда, не всегда получается. Получается примерно в 90% соучаев, но иногда легче написать код, а потом его протестировать. Проблема с таким подходом в том, что тестируя ПОСЛЕ вы (как человек неглупый) применяете дополнительные знания о том КАК работает ваш код.

Но, как человек, склонный ошибаться (а все люди склонны ошибаться) Вы сами толком не знаете, КАК работает Ваш код, иначе Вам вообще не нужны тесты. Вам знаком такой принцип — "никогда не доверяй тестирование автору программы" ? Вам знакомо такое выражение — "Уж НА ЭТОТ раз моя программа работает верно!". Думаю, что да. Написание же тестов ДО кода не дает Вам возможности применить заранее Ваши (возможно, ошибочные) догадки о собственном коде. В этом одно из преимуществ такого подхода.

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

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

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

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

Большая система или малая не особо и играет роль. Я бы писал тесты для тех мест, которые вызывают сомнения, другими словами уничтожал соменения покрытием тестов.

A.J. -> "Re[4]: Test Driven Development — только для простеньких клас" :

hrg>> Я вроде в этой эхе расписывал, как это делается.
hrg>> Вкратце — что такое иерархия элементов — это дерево. У тебя
hrg>> функции построения дерева.
hrg>> Берешь кусок документа и строишь для него дерево руками.
hrg>> Потом запускаешь парсер и смотришь, что он тебе построил.
hrg>> Если два дерева идентичны — то тест прошел.

A> Ну да. И все, в чем я могу быть после этого уверен — то, что данный
A> конкретный документ преобразуется правильно.

Ключевые слова: декомпозиция, граничные тесты.

Yury Kopyl aka hrg | http://id.totem.ru | "Бей врага — друзья найдутся"(С)
Жванецкий

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

hrg>A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :

A>> Здравствуйте, Павел Леонов, Вы писали:

A>> Так получается, тесты проверяют лишь минимальную функциональность.

hrg>(поперла философия

Ну так названия форума подходящее


hrg>Тесты проверяют только то, что ты написал. Тесты не
hrg>явлются мыслящим существом и тем более не обладают телепатическим даром.
hrg>Тесты не увеличивают радиус кривизны рук

Ну, я тоже телепатическим даром не обладаю. Я, конечно, могу придумать несколько
ситуаций, когда мое решение _возможно_ не сработает.

Но хочется ведь помечтать о взаимнооднозначном отношении
требование — набор тестов.

Т.е. если набор тестов проходит, то можно быть на 100% уверенным, что требование
выполняется. Так для простых требований это выполняется — написать такие тесты особой проблемы не представляет.

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

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

AJ>Здравствуйте, Павел Леонов, Вы писали:

ПЛ>>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.

AJ>Так получается, тесты проверяют лишь минимальную функциональность. Типа, "по крайней мере в одном случае (чаще всего простейшем) оно работает!"

AJ>Ну тогда не надо называть это тестами. Менее бы вводило в заблуждение что-нибудь вроде "иллюстрации простейшего использования"

Почему? "Если это выглядит как тест и выполняется как тест..." (с) Тем более что подобные тесты — имхо, хорошая основа для regression тестов.

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

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

У меня в своё время похожая ситуация была: Был набор классов, которые только в совокупности и правильно настроенные представляли ценность. Ну и работа, которая ими выполнялась была далекоооо не тривиальна. Ну и use-case-ами плохо описывалась.
В общем, тестировать каждый класс в отдельности — означало писать какие-то тривиальные (в смысле функцианирования, а не в смысле написания) заменители для всех остальных — долго, муторно и польза сомнительная...

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

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

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

А в конце концов, у меня сложилось впечателние, что для сложных систем, там где применение unit test-ов затруднительно, более удобно применять какие-то вариации программирования по контракту.

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

я думаю, дело в том, что обычно автоматически тестируют отдельные фрагменты программ.
Протестировать полностью действительно большую систему с помощью таких вот тестов-автоматов просто невозможно. Ну вот как тестировать многопоточный сервер, например? Если там есть проблемы с синхронизацией, можно хоть 10 лет тесты писать и потом еще 10 лет их гонять, и все равно что-то пропустить. Потому что ошибка проявляется только при полной луне и одном строго определенном уровне прилива в Бразилии
Слишком много тестовых случаев, слишком много возможных неучтенных связей.
В этом случае, вероятно, нужно просто сосредоточиться на самых важных аспектах системы, а на остальное забить.

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

V>Лучше иметь психологический обман, чем не иметь не чего.
А Вы сами задумывались над фразой, которую написали?

А-ля "Лучше иметь пинок под зад, чем ничего не иметь"

V>}{орошо. Попробую привести один маленький пример, почему тесты лучше писать по всему процессу создания программы.
[ поскипано ]

Гранд мерси Вам за поучительную историю сложения 2+2
По-моему, тут имеет место некоторое недопонимание того, что я пытался сказать. См ниже.

V>,а теперь вопрос, почему нельзя было сделать в самом начале тест на создание пользователя?! Код написанный в GUI и WEB перенести в тест и в любой момент мы можем его запустить и посмотреть как работает функция создания пользователя, не запускать GUI или WEB, а запустить тест и понять кто плохой, наш прецедент сломался или все хорошо.

ёпрст. Я же специально в одном из своих постов сказал что я НЕ ПРОТИВ тестирования! Я ЗА тестирование. Но писать тесты перед написанием тестируемого кода — это противоречит работе нормального программистского мозга. Мозг мыслит абстрактными вещами, а тесты — конкретными примерами. Мозг прибегает к конкретным примерам, только в исключительных ситуациях — когда абстрактно не получается мыслить. А TDD навязывает именно способ мышления use-case-ами!

Я не выступаю против тестирования! Я выступаю против мышления тестами %)

V>Посмотрим по времени сколько это может занять... могу заявить авторитетно создание теста займет, 2 минуты. Мое резюме. Заплатить 2 минуты что бы спать спокойно, оно того стоит.

А моё резюме, соответственно, такое: Тесты нужно писать именно тогда, когда возникает в этом необходимость.

ЗЫ. И, по-моему, оба наших резюме не противоречат друг другу.

XopoSHiy -> "Re[4]: Test Driven Development — только для простеньких клас" :

X> ёпрст. Я же специально в одном из своих постов сказал что я НЕ ПРОТИВ
X> тестирования! Я ЗА тестирование. Но писать тесты перед написанием
X> тестируемого кода — это противоречит работе нормального
X> программистского мозга. Мозг мыслит абстрактными вещами, а тесты -
X> конкретными примерами. Мозг прибегает к конкретным примерам, только в
X> исключительных ситуациях — когда абстрактно не получается мыслить. А

Была хорошая фраза в ФИДО — отучаемся говорить за всех

X> TDD навязывает именно способ мышления use-case-ами!

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

X> Я не выступаю против тестирования! Я выступаю против мышления тестами
X> %)

"Это твоя сугуболичная беда"(С)

V>> Посмотрим по времени сколько это может занять... могу заявить
V>> авторитетно создание теста займет, 2 минуты. Мое резюме. Заплатить 2
V>> минуты что бы спать спокойно, оно того стоит.

X> А моё резюме, соответственно, такое: Тесты нужно писать именно тогда,
X> когда возникает в этом необходимость.

Угу. И будешь как Vlad2 — это же скока их надо написать то? И сразу, заметь.
Сидишь и пишешь тесты. День пишешь, два пишешь. Очень увлекательно и
познавательно. И главное сильно мотивирует.

Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку
за наши молитвы."

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

XSH>Но я не могу писать тесты ДО. Это коряво! Это идет в разрез с образом моего мышления. Это не поддерживает моя среда разработки, наконец!
XSH>Я пишу тесты. Но я это делаю ПОСЛЕ напиания кода.

А ты никогда не сталкивался с ситуацией, когра красиво и грамотно спроектированная группа классов, оказывается неудобной в использовании? Тесты "ДО" дают своего рода маяк (ориентир), к чему следует стремиться. Идеал системы с точки зрения ее пользователя. В противном случае часто проектирование происходит ради самого процесса проектирования, без конечной цели. Конечно, цель держится в голове (иногда про нее забывают, заменяют, ...), ввиду ее расплывчатости возникает больше альтернатив, больше вариантов выбора, больше простора для мысли. Наличие цели сковывает, но оно необходимо.

Сравни: необходимо реализовать B2B проект. И ты сразу же начинаешь проектировать, придумывать свою функциональность, наслаждаться прототипами классов, которые ты впоследвии реализуешь, строить архитектуру. Сразу включается фантазия, полет мысли... А вот тебе принесли воемь книг, в котором описано ТЗ по В2В проекту. И тебя это отнюдь не окрыляет

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

B>http://www.pyrasun.com/mike/mt/archives/2004/07/10/18.43.16/index.html
Касательно этой статьи. Заслуга JUnit, как правильно омечает автор, вовсе не в его коде, а в том, что это была первая удачная и простая реализация framework'а для тестирования.
Я посмотрел в исходный код junit, как это советовал сделать автор. Ничего особо смешного я не нашел. Быть может, автору смешно, что реализация НАСТОЛЬКО проста ??? Быть может автор с бОльшим удовольствием увидел бы там зашифрованный алгоритм метода трехточечной прогонки для решения диф. уравнений? В общем, сарказм автора по поводу простоты JUnit считаю неуметсным, потому как простота — сестра таланта.

Далее автор ругает Mock объекты, как неверный способ тестирования. Спорный вопрос, касающийся Ваших предпочтений и соображений по поводу технологий тестирования. Я не стану комментировать содержание, однако стиль изложения очень мне не понравился. Грубо, к тому же есть попытки очернить Фулера как такового, как личность, не рассматривая излагаемые им факты. Неуместная практика в научных дискуссиях.

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

Вместе с тем, автор все-таки не осмеливается прямо заявить, что unit testing — это плохо. Уж слишком очевиден результат применения подхода.

Никто не запрещает автору написать лУчшую библиотеку, если он считает это нужным. А так, автор намекает на заоблачные высоты, функциональность, гораздо более мощную, чем предоставляет JUnit, снисходительно упоминает, что вот ОН-то, конечно, использует какие-то способы тестирования, иные чем JUnit, но прямо об альтернативах (кроме, опять же вскользь упомянутого TestNG) не говорит.

В заключение автор пишет: "Focus on unit testing with the mania that a Fowler or Eckel do, and you too will end up with a toy app that breaks under any serious load."
Каким же это образом, интересно, тесты, ортогональные по своей сути к коду программы (я имею в виду, что их можно вовсе выкинуть из релиза) способны привести к медленной программе ? Или автор считает что ВРЕМЯ потраченное на тестирование не окупится ???

Вторую статью прочитать пока не успел.

Заранее прошу прощения если подобный вопрос уже поднимался — поиском не нашел.

Прочел очередную статейку по Test Driven Development и опять — взяло меня deja vu. Автор берет какой-нибудь простенький изолированный класс типа Money или мало кому нужный типа TriangleAnalyser и весело пишет для него юнит тесты. "Конечно", — думаешь, -"для такого класса написать тесты — пара пустяков."

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

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

Просто надоело — пишутся тесты только для "написанных с нуля" простеньких собственных классов — а про то, как действительно важные вещи протестировать — нигде не слова. Интересно, может ли быть сформулировано правило, по которому можно протестировать практически любой кусок программы?

Реакции типа "да ты нифига не понял в этой жизни" принимаются тоже, при наличии аргументации

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

hrg>Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как
hrg>правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую
hrg>електроникой грань, все встанет на свои места

То есть получается — если уже начал писать программу без ТДД, то все, поезд
ушел?

В принципе вопрос не отменяется — можно ведь и с нуля писать прогу, которую будет очень трудно протестировать.
Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?

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

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

А можно поподробнее про smoke тестирование? Просто нигде раньше не встречал такого термина.

A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :

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

hrg>> Как ты думаешь — почему это называетя "Разработка через тесты", а
hrg>> не "Как правильно тестировать программы"? Когда уловишь эту
hrg>> тонкую, едва различимую електроникой грань, все встанет на свои
hrg>> места

A> То есть получается — если уже начал писать программу без ТДД, то
A> все, поезд ушел?

Нупочимужи? Просто часть проги у тебя будет непокрытой тестами. Потом ее
привелешь к нужному виду.

Кстате — TDD очень хорошо завязан на реализацию use-case'ов.

A> В принципе вопрос не отменяется — можно ведь и с нуля писать прогу,
A> которую будет очень трудно протестировать.
A> Как, скажем, будет выглядеть тест (или набор тестов), проверяющий
A> выполнение такого требования: любой XHTML-документ, соответствующий
A> DTD, должен быть корректно преобразован в собственное программное
A> представление (иерархию элементов)?

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

Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку
за наши молитвы."

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

ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.

Так получается, тесты проверяют лишь минимальную функциональность. Типа, "по крайней мере в одном случае (чаще всего простейшем) оно работает!"

Ну тогда не надо называть это тестами. Менее бы вводило в заблуждение что-нибудь вроде "иллюстрации простейшего использования"

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

AJ>>То есть получается — если уже начал писать программу без ТДД, то все, поезд
AJ>>ушел?

_>Не совсем.
_>Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения.
_>Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.

Так вопрос в том — чем этот "новый" вид отличается от старого-то?? (при условии, что система хорошо спроектирована, декомпозиция задачи выполнена грамотно, и т.п.)

AJ>>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?

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

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

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

hrg>A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :

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

hrg>Я вроде в этой эхе расписывал, как это делается.
hrg>Вкратце — что такое иерархия элементов — это дерево. У тебя функции
hrg>построения дерева.
hrg>Берешь кусок документа и строишь для него дерево руками.
hrg>Потом запускаешь парсер и смотришь, что он тебе построил.
hrg>Если два дерева идентичны — то тест прошел.

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

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

K>Может тут есть что интересного:

K>http://weblogs.asp.net/wallen/

K>Practical Testing
K>Len Holgate is writing a series of posts on Unit Testing with a non-trivial example. Good stuff, check it out.

Похоже как раз то, что надо Спасибо

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

AJ>Но хочется ведь помечтать о взаимнооднозначном отношении
AJ> требование — набор тестов.

если имелось в виду "отношении" = "отображении", то очевидно, такого отображения просто не существует %)
Д/з: за 15 секунд понять почему

AJ>Т.е. если набор тестов проходит, то можно быть на 100% уверенным, что требование
AJ>выполняется. Так для простых требований это выполняется — написать такие тесты особой проблемы не представляет.
ну-ну. Напиши ка мне тест для процедуры сложения двух действительных чисел

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

Тестировать всегда можно ТОЛЬКО на частных случаях. Правда, исходя из знания того, как устроена "решалка" можно найти набор частных случаев, полностью проверяющих "решалку". Но тогда набор тестов будет зависить от внутреннего устройства "решалки"! И никакой тебе инкапсуляции, понимаешь ли...

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

XSH>если имелось в виду "отношении" = "отображении", то очевидно, такого отображения просто не существует %)
XSH>Д/з: за 15 секунд понять почему

Да, я конечно немного хватанул "того"

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

XSH>Тестировать всегда можно ТОЛЬКО на частных случаях. Правда, исходя из знания того, как устроена "решалка" можно найти набор частных случаев, полностью проверяющих "решалку". Но тогда набор тестов будет зависить от внутреннего устройства "решалки"! И никакой тебе инкапсуляции, понимаешь ли...

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

A.J. -> "Re[4]: Test Driven Development — только для простеньких клас" :

A> Но хочется ведь помечтать о взаимнооднозначном отношении требование
A> — набор тестов.

Отображении. есть правило 20/80. (его формулируют разными словами, но смысл
один и тот же).
Трудозатраты на 100% покрытие растут не линейно.
Прикидываешь, каковы трудозатраты на ловлю ошибок после, и сколько до,и,
найдя точку пересечения этих кривых, останавливаешся

A> Т.е. если набор тестов проходит, то можно быть на 100% уверенным, что
A> требование выполняется. Так для простых требований это выполняется -
A> написать такие тесты особой проблемы не представляет.

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

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

Yury Kopyl aka hrg | http://id.totem.ru | "бысто сп..ил и ушел — называется
нашел..."

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

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

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

AJ>А можно поподробнее про smoke тестирование? Просто нигде раньше не встречал такого термина.
Цель этих тестов — проверить выполняет ли правильно тестрируемая ф-ция/класс/программа свою задачу. Обычно это одни из самых простых сценариев.

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

hrg>>Тесты проверяют только то, что ты написал. Тесты не
hrg>>явлются мыслящим существом и тем более не обладают телепатическим даром.
hrg>>Тесты не увеличивают радиус кривизны рук

AJ>Ну, я тоже телепатическим даром не обладаю. Я, конечно, могу придумать несколько
AJ>ситуаций, когда мое решение _возможно_ не сработает.

AJ>Но хочется ведь помечтать о взаимнооднозначном отношении
AJ> требование — набор тестов.

AJ>Т.е. если набор тестов проходит, то можно быть на 100% уверенным, что требование
AJ>выполняется. Так для простых требований это выполняется — написать такие тесты особой проблемы не представляет.

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

Я лично пишу обычно базовый набор тестов для критичных компонент (ну и не очень критичных) по возможности и
"компенента <-> компонента". Обычно это базируется на типичных use-case тестируемых компонент. И еще несколько
для проверки . Далее при добавлении/изменении функциональности тесты позволяют отследить сломаные завистимости.
И тесты никогда не получается написать сразу для всего, обычно они обрастают всякими допольнительностями по мере
разработки и обнаружнения новых багов. Т.е. это что-то вроде документации, которая тоже пишется вместе с проектом.
(не ТЗ, а именно документация )

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

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

AJ>>>То есть получается — если уже начал писать программу без ТДД, то все, поезд
AJ>>>ушел?

_>>Не совсем.
_>>Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения.
_>>Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.

AJ>Так вопрос в том — чем этот "новый" вид отличается от старого-то?? (при условии, что система хорошо спроектирована, декомпозиция задачи выполнена грамотно, и т.п.)

Новый вид создан с точки зрения использования. Старый в большинстве случаев с точки зрения реализации. Стоит попробовать, чтобы почувствовать разницу.

AJ>>>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?

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

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

Это уже integration testing. А как ты помнишь, TDD включает в себя только unit-testing. Но с другой стороны при обнаружении бага ты можешь написать integration test на него, чтобы он больше не возникал.

И вообще-то, по большому счету, тестирование в TDD не самое важное. Самое важное это Test-First Design, т.е. дизайн, рождающийся благодаря априорному наличию требований, выраженных в коде.

Но так удачно получилось, что требования и unit-testing реализованы в одном лице (в виде unit-тестов). Собственно от тестов с точки зрения именно тестирования требуется лишь хорошее покрытие кода с тем, чтобы без боязни применять refactoring. Который в свою очередь является механизмом поддержки evolutionary design, и если копнуть дальше, то и самого ООП...

Я бы описал сие следующим образом:

TDD = test-first design (requirements) + unit-testing (foundation) + refactoring (evolutionary design) + feedback (justifies refactoring, hence evolutionary design)

Тогда OOP отлично реализуется как object decomposition + TDD.

--

Владимир.

XopoSHiy -> "Re[7]: Test Driven Development — только для простеньких клас" :

X> А в конце концов, у меня сложилось впечателние, что для сложных
X> систем, там где применение unit test-ов затруднительно, более удобно
X> применять какие-то вариации программирования по контракту.

Все клева. Но как контракт спасиет от ошибок в самом классе?

Yury Kopyl aka hrg | http://id.totem.ru | "Сегодня с нами ты не пьешь, а
завтра Родине изменишь!"

hrg>Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как
hrg>правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую
hrg>електроникой грань, все встанет на свои места

Давай рассказывай — с чем ты несогласен?

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

hrg>XopoSHiy -> "Re[7]: Test Driven Development — только для простеньких клас" :

X>> А в конце концов, у меня сложилось впечателние, что для сложных
X>> систем, там где применение unit test-ов затруднительно, более удобно
X>> применять какие-то вариации программирования по контракту.

hrg>Все клева. Но как контракт спасиет от ошибок в самом классе?

Никак естественно! Ничто не спасает от ошибок в самом классе

Но если есть ошибки, то наверняка где-то в контракте нарушится либо предусловие либо постусловие.
И, соответственно, если ни предусловия ни постусловия нигде не нарушились, то, скорее всего, ошибок нет.

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

XSH>ёпрст. Я же специально в одном из своих постов сказал что я НЕ ПРОТИВ тестирования! Я ЗА тестирование. Но писать тесты перед написанием тестируемого кода — это противоречит работе нормального программистского мозга. Мозг мыслит абстрактными вещами, а тесты — конкретными примерами. Мозг прибегает к конкретным примерам, только в исключительных ситуациях — когда абстрактно не получается мыслить. А TDD навязывает именно способ мышления use-case-ами!
ИМХО — это хорошо! Вместо абстракного " это будет работать так-то и так-то" конкретное — это будет работать именно так! Как написано в тесте — он же конкретно использует (еще не написанный!!!!!) код.
XSH>Я не выступаю против тестирования! Я выступаю против мышления тестами %)
Нет, не тестами, а конкретным использованием. Тут не в тестах дело, а именно в конкретизации использования.В том и кайф, что еще не написанный код — реально используется и тут-то вылезают (еще до написания!!!) неудобства и возможные "пенки" абстрактных мыслей по поводу абстрактной работы этого куска программы

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

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

Дубль 3: Я не против тестов . Я за тесты как таковые. Почти все аргументы за TDD приведённые мне выглядят примерно так:
"тесты — это хорошо потому-то и потому-то, поэтому надо тестировать!". Это я и сам знаю. Я и сам люблю "продолжать с хорошим настроением".
Но я не могу писать тесты ДО. Это коряво! Это идет в разрез с образом моего мышления. Это не поддерживает моя среда разработки, наконец!
Я пишу тесты. Но я это делаю ПОСЛЕ напиания кода.

В предыдущем посте Вы высказали то мнение, высказывания которого я ждал с самого начала дискуссии:
Тест — это еще и испытание удобности изобретаемого интерфейса класса.
За это тебе и "+".

На мой взгляд это единственная разумная причина, по которой тесты следует писать ДО.
Другое дело, что это немножко другие тесты: тесты интерфейса. И они вовсе не обязаны быть автоматическими. Их бессмыслено включать в unit-test-ы. Они в принципе могут не исполняться. Эти тесты (тестирование удобности интерфейса) я действительно пишу ДО написания кода, но я это делаю карандашиком на листочке бумаги формата А4!

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

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

V>>Лучше иметь психологический обман, чем не иметь не чего.
XSH>А Вы сами задумывались над фразой,
XSH>которую написали?
Исправим,
Лучше иметь "психологический обман", чем не иметь не чего.
XSH>А-ля "Лучше иметь пинок под зад, чем ничего не иметь"

V>>}{орошо. Попробую привести один маленький пример, почему тесты лучше писать по всему процессу создания программы.
XSH>[ поскипано ]

XSH>Гранд мерси Вам за поучительную историю сложения 2+2
XSH>По-моему, тут имеет место некоторое недопонимание того, что я пытался сказать. См ниже.
Как в той притче, один прутик можно сломать легко, два то же, но метлу...
Все тесты настолько просты, что кажутся сложением 2+2, но вместе они СИЛА.

Пара примеров из жизни(просто так)

        /// <summary>
        /// Находим какие преподаватели читают курс.
        /// 
        /// </summary>
        [Test]
        public void TrainerByCourse()
        {
            BusinessLogic.Courses.Course c = new BusinessLogic.Courses.Course(23);
            TrainerCourseCollection tcc = new TrainerCourseCollection(c);
            tcc.Load();
            Assert.True(tcc.Count != 7, "Не правильно загрузилась коллекция.");
        }

        /// <summary>
        /// Проверяем поиск роли у пользователя.
        /// </summary>
        [Test()]
        public void IsInRole() 
        {
            User testObject = new User(1);
            Assert.True(testObject.IsInRole(UserRole.Administrator), "Не правильно выполнился метод IsInRole");
        }

V>>,а теперь вопрос, почему нельзя было сделать в самом начале тест на создание пользователя?! Код написанный в GUI и WEB перенести в тест и в любой момент мы можем его запустить и посмотреть как работает функция создания пользователя, не запускать GUI или WEB, а запустить тест и понять кто плохой, наш прецедент сломался или все хорошо.

XSH>ёпрст. Я же специально в одном из своих постов сказал что я НЕ ПРОТИВ тестирования! Я ЗА тестирование. Но писать тесты перед написанием тестируемого кода — это противоречит работе нормального программистского мозга. Мозг мыслит абстрактными вещами, а тесты — конкретными примерами. Мозг прибегает к конкретным примерам, только в исключительных ситуациях — когда абстрактно не получается мыслить. А TDD навязывает именно способ мышления use-case-ами!
Второй пример, это не Use-case это функция выполняемая в use-case. Скажу честно я то же не могу.
Мои шаги такие.
Ставлю задачу проверить существует ли определенная роль у пользователя.
Определяю что это будет метод, свойство или поле. одним словом расширяю спецификацию класса.
Пишу в классе пустой метод. Компилирую. Все ок. Перехожу к тестам. Создаю тест. Инициализирую тестовые данные.
Вызываю тестируемый метод. Компилирую. Все ок. Запускаю новый тест. Зеленая полоса. Начинаю реализацию. Метода.
Получаю правильно работающий метод, И зеленую полосу в тесте. Все рады и счастливы.

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

XSH>Лично я, когда начинаю прогу писать, не use-case-ами мыслю. Это только если совсем тяжко и туго — на примерах разбираю, что и как должно быть. А в основном пытаюсь мыслить максимально абстрактно.

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

А вот на практике: надо написать программу для игры в крестики-нолики (3х3). Подойдем к вопросу более общно. Пусть имеется некая игра двух лиц, вроде шашек, шахмат, ... Нужно написать общую библиотеку, позволяющую упростить реализацию подобных игр, разрабатывая отдельно визуализацию, чтение выбора игрока, выбор компьютера, отладку алгоритмов... Далее, время хода обычно ограничено. Следовательно, каждый ход должен запускаться в отдельном потоке, необходимы механизмы для того, чтобы алгоритм мог узнавать, сколько времени ему осталось на обдумывание и (для полноты картины) сколько времени осталось противнику. Далее, в игур могут играть не только двое, но и твое, четверо. Иногда в игру может вмешиваться случаный фактор. Кроме того, не всегда ходы выполняются последовательно. Хорошо бы еще учесть возможность игры по сети. ... Пишем время реализации задания --- человекопятилетка.

Мыслить абстрактно это конечно же хорошо, но может все надо делать в меру?

Любой модуль, любой класс по сути имеет две стороны медали:
1) сужает возможности (TStream не позволяет напрямую управлять кешированием файловых операций, делать асинхронный ввод/вывод)
2) упрощает или стандартизирует часто используемые применения.

Use-cases как раз дают большую информацию по второму пункту. Это как бы привязка к практическим потребностям класса или модуля. Абстрагирование же призвано расширить возможности (часто без надобности, подскольку в 1% случаем можно и напрямую обратиться к FileCreate, ...).

Особую ценность имеют пилотные проекты, т. е. прокты, которые потом переписываются с нуля. Но позволяющие лучше определить архитектуру системы. Имхо, одним из недостатков традиционных методов проектирования (СОММЕТ, например) это то, что проетирование производится отдельно от кода, а зачастую и отдельно от существующих библиотек, ...

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

AJ>Ну да. И все, в чем я могу быть после этого уверен — то, что данный конкретный
AJ>документ преобразуется правильно.

А ты хочешь проверить правильность парсинга ВООБЩЕ всех документов, возможных в природе?? Это в самом деле длительный и трудоемкий процесс, тут уж тебе никакие TDD не помогут

Как-то дискуссия увяла. А так интересно было читать...
Чтобы подогреть интерес к теме — вот пара отзывов на недавно опубликованную статью Мартина Фаулера Mocks Aren't Stubs:
http://www.pyrasun.com/mike/mt/archives/2004/07/10/18.43.16/index.html
http://www.pyrasun.com/mike/mt/archives/2004/07/11/15.41.04/index.html

XSH>Лично я, когда начинаю прогу писать, не use-case-ами мыслю. Это только если совсем тяжко и туго — на примерах разбираю, что и как должно быть. А в основном пытаюсь мыслить максимально абстрактно. Таким вот образом TDD и вступает в противоречие с моим ходом мыслей (и не только с моим, на сколько я знаю). В том смысле, что любой тест — это по сути, как уже было отмечено выше, проверка работы на каком-то конкретном примере (use-case), а мыслю я далеко не конкретными примерами.
XSH>А по скольку я искренне уверен, чно нормальный программист должен мыслить именно так как я, то и считаю TDD неадекватной методой....
XSH>Не в том смысле, что тестировать не надо, а в том смылсе, что тесты не являются первичными при разработке Это неестественно.

Ты пойми, вопрос не в том что первично а что вторично. Вопрос в том кто сделает качественне, бустрее и дешевле.
И в конечном итоге никого не будет волновать как сделано. Важен сам результат. Так вот люди придумали как им
решить задачу — сделать качественее, быстрее и дешевле. Придумали способ — TDD (и XP в целом). Этот способ показал хорошие результаты. Поэтому его и испольуют. В конечно итоге кол-во нулей показывает кто был прав а кто нет.

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

AJ>Просто надоело — пишутся тесты только для "написанных с нуля" простеньких собственных классов — а про то, как действительно важные вещи протестировать — нигде не слова. Интересно, может ли быть сформулировано правило, по которому можно протестировать практически любой кусок программы?

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

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

Вообще, вроде бы, встречаются программы с открытым кодом, содержащие юнит-тесты. Надо поискать...

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

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

Мне кажется проблема в воспрятии. Не надо пытаться написать все тесты. Надо написать те, которые позволят тебе убедиться, что код, на вид работает. 100% покрытие не требуется, он нужны для разработки, а не для тестирования.

S>Ты пойми, вопрос не в том что первично а что вторично. Вопрос в том кто сделает качественне, бустрее и дешевле.
S>И в конечном итоге никого не будет волновать как сделано. Важен сам результат. Так вот люди придумали как им
S>решить задачу — сделать качественее, быстрее и дешевле. Придумали способ — TDD (и XP в целом). Этот способ показал хорошие результаты. Поэтому его и испольуют. В конечно итоге кол-во нулей показывает кто был прав а кто нет.

Товарищч Mystic!

Поршу прощения, но Вы пытаетесь сейчас давить авторитетами, а именно TDD и XP. То, что Вы пишете, конечно, вполне верно, но не самый лучший способ объяснить человеку почему он должен поступать так или иначе. Извините, но это смахивает на объяснение типа — все так делают, глупый, и ТЫ тоже так делай, а не то над тобой смеяться будут.

Вопрос о том, что первично, а что — вторично очень важен. Вот товарищч именно не понимает, почему нужно СНАЧАЛА писать тесты, а не потом.

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

AJ>Так получается, тесты проверяют лишь минимальную функциональность. Типа, "по крайней мере в одном случае (чаще всего простейшем) оно работает!"

TDD рекомендует делать так:
1) Написал простейший тест
2) Нписал простейшую реализацию простейшего теста
3) Написал тест посложнее
4) Написал релизацию, которая умеет проходить тесты 2 и 3

И верно, если Вы "в лоб" будете применять такую "методоологию", то код ваш будет похож на заплатки в Windows:

if (case1)
return res1
else if (case2)
return res2
else if (case3)
...


Однако, в описании TDD упускается один важный принцип.

ПРИНЦИП ПРОСТОТЫ
Лучшим решением проблемы является наиболее простое, краткое, понятное решение.

Если Вы будете руководствоваться этим принципом, то после 3-4го теста поймете, что вообще-то задачу легче и понятней решить абстрактно, а не рассматривая каждый конкретный случай.

Если говорить в общем (не только о TDD)
Не надо слепо следовать интсрукциям. Вам платят за то, что Вы человек, а не за то, что Вы компьютер. Никакая методология тестирования или написания программ не отменяет Вашего головного мозга. Если Вы считаете, что так будет более понятно, легко, гибко и сопровождаемо, то идите даже наперекор методологии. Но при этом имейте в виду, что случаев, когда Вы ДЕЙСТВИТЕЛЬНО лучше можете сделать, чем это предлагает метод, как правило очень мало.