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

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

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

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

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

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

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 | Гордость мешает доходам!

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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.

--

Владимир.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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