Здравствуйте, 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>Здравствуйте, тёзка
XSH>Вы писали:

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

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

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

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

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

--

Владимир.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я, например, очень хочу чтобы для меня 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% покрытие не требуется, он нужны для разработки, а не для тестирования.

Здравствуйте, _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 раз переписан и частично выброшен.

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

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

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

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

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

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

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

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

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)
Не надо слепо следовать интсрукциям. Вам платят за то, что Вы человек, а не за то, что Вы компьютер. Никакая методология тестирования или написания программ не отменяет Вашего головного мозга. Если Вы считаете, что так будет более понятно, легко, гибко и сопровождаемо, то идите даже наперекор методологии. Но при этом имейте в виду, что случаев, когда Вы ДЕЙСТВИТЕЛЬНО лучше можете сделать, чем это предлагает метод, как правило очень мало.

Здравствуйте, 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."
Каким же это образом, интересно, тесты, ортогональные по своей сути к коду программы (я имею в виду, что их можно вовсе выкинуть из релиза) способны привести к медленной программе ? Или автор считает что ВРЕМЯ потраченное на тестирование не окупится ???

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