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

FDS>1. Такую длительную проверку вряд ли кто-то будет вставлять

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

FDS>2. Проводить проверку или нет решает пользователь, если она занимает длительное время

Вот именно. А если от пользователя это скрыто и никак на это повлиять нельзя, то...

FDS>3. Если результат значимый (я, например, занимаюсь расчётами на прочность), то некоторые проверки просто ОБЯЗАТЕЛЬНЫ и сколько они времени занимают уже не так важно. Разработчик всегда вставляет довольно быстрые проверки, а пользователь всегда хочет быть уверенным, что программа сделала всё возможное, для того, что бы недопустить выдачу некорректного результата там, где это недопустимо.

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

6. Прямо в коде пишется небольшой тест который проверяет граничные случае, размытие изображения 0x0 размытие изображения 1x1, 1x100, 100x1 и т.п. Этот замечательный тест запускается при первом обращении к функции размытия и выполняется только один раз на запуск (напрмиер контролируется статической переменной).
Это наш регрешен о котором даже не надо заботится, не надо запускать его каждый раз после внесения изменений и т.п.

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

M>Индикатор статуса проекта у меня зеленый, т.е. инвариант (проект должен быть зеленым — сохраняется), с другой стороны мне ясно видно какие из тестов не up-to-date, и должны быть подняты.

В таком случае, это намного лучше чем красный. Но зелёный все равно лучше

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

C>Как раз большая часть ошибок происходит из-за того, что свежий код
C>ломает другой код.

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

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

AVK>>(а мы ведь здесь все специалисты именно по сложному коду, не так ли?)

IT>Не так.

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

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

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

M>>ЮТ только стремятся быть локальными и тестировать каждый модуль отдельно. Но это не всегда возможно и очень часто НЕУДОБНО.
GZ>Есть Юнит тесты, есть интеграционные тесты. Провести между ними грань практически невозможно, потому как непонятно, то ли мы тестируем один модуль на основе данных второго модуля в предположении что второй точно работает, то ли мы тестируем оба модуля и как они работают вместе. Тут все скользко, и я особо их не разделяю между собой(кроме случая когда делаются модули различными группами).
M>>СК — локален абсолютно , для него открыты все внутренности классов и модулей в отличие от ЮТ.
GZ>И это недостаток. У нас тесты будут зависимы именно от реализации, а не от результата. Как результат, любая адаптация реализации понесет за адаптацию тестов в лучшем случае. В худшем, поскольку они могут находится в любой части кода — непонятному появляению assert когда все хорошо работает.

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

Расскажите плиз , как бы вы тестировали такой модуль. ?


M>>Плюс ЛЮБОЙ запуск программы теперь становится нашим тестом ! Представте насколько вырастает к-во оттестированных ситуаций. Любой пользователь вашего модуля становится вашим тестером (халява)!
GZ>А нужно ли это пользователю? Для того чтобы обеспечивать корректную информацию об ошибках в процессе работы пользователя — нужно строить совершенно другие механизмы. В котором есть информация предназначенная пользователю, а есть информация предназначенная службе сопровождения/разработки.

Ок. Мне и в голову не могло прити что ктонибудь может допустить мысль отдать конечному пользователю отладочный код , который используется в процессе разработке. Такую ситуацию я допускаю , но такой отладочный код является частью системы (напрмиер логирование неожиданных ситуаций) и к нему предъявляются такие же критерии качества как и к системе.
Под "пользователями" я подразумевал , ваших колег которые будут работать в процессе интеграции с вашим модулем , тестеры , и бета тестеры.
Мне кажется очевидным что тот регрессион из моего примера , необходимо запустить только один раз после внесения изменений , и выполняться каждый раз у конечного пользователя — бессмысленно.

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

M>>3. Встроенность в код.
M>>Вероятно многие знают , насколько это геморойно , изменяя код ,переписывать и юнит тесты. Это может просто ЗЛИТЬ, чувство потерянного впустую времени.
GZ>Не изменяя код. А изменяя интерфейс или функциональность. Это очень разные вещи. К тому же, обычно кто реализует, тот и пишет тест.

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

M>>4. Постепенный рефакторинг , вместо полного переписывания.
M>>Часто встречал такую мысль: Этот код не был приспособлен к юнит тестам , и его легче полностью переписать заново , чем приспособить к юнит тестированию. при использовании СК , такой проблемы нет (следствие пункта 1).
GZ>Есть два подхода. 1. Писать сразу начиная с unit-тестов тестируемый код. 2. После того как написал думать о том, как бы присобачить unit-тесты ко всей этой шараге функций. В данном случае ты говоришь именно о нетестиремом коде, и в этом случае уже нужно считать сколько-что будет стоить, и на фиг это нужно.

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

M>>Опять хочу отдельно отметить, что самым разумным считаю СОЧЕТАНИЕ всех методик. Но совершенно неразумно забывать какие грандиозные преимущества дает СК, ОСОБЕННО это касается разработки в экстремальных ситуациях , нехватка времени , и т.п.
GZ>Например, когда отдают клиентам дебугнутые версии. Потому как релиз проверить решили в последний момент, за что и поплатились.

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

M>>ПРИМЕР 1:
GZ>Ничего не понял. У тебя задача построить корректный алгоритм размытия. У тебя есть условия — границы, прозрачность. У тебя есть алгоритм который ты считаешь корректным. Так что тебе мешает проверить новый алгоритм на условия с помощью unit-тестов на этапе реализации?

Да вообще ничиго! Я не считаю принципиальным создать отдельный проект с заумным названием юнит тест , если я могу все что мне надо оттестировать на месте.

Преимущества я писал , вы не согласны. Мне реально хочется узнать почему , и если можно с маааленьким примером. Я не уверен в своей правоте на 100% , и поэтому хочется послушать коментарии по делу. Ваш пост пока один по делу , спасибо.


P.S. не думаю что смогу сформулировать догматичные правила по СК. Вот например недавно я оставил в релизном варианте кода проверки такого плана.

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

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

AVK>Здравствуйте, Lazy Cjow Rhrr, Вы писали:


AVK>Начнем с того, что я очень люблю рефакторинг. Мне вобще кажется, что сложный код (а мы ведь здесь все специалисты именно по сложному коду, не так ли?), который не отрефакторили раза три, скорее всего будет не очень качественным. Поэтому на начальных этапах своей жизни мой код выполняет значительные пертурбации, прежде чем придет в сравнительно устойчивое состояние.
AVK>А в рефакторинге главное что? В рефакторинге главное простота его производства. Чем проще и дешевле рефакторинг, тем более глубоким он будет при тех же затраченных усилиях.

Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior. Neil Roodyn recommends that "if you refactor, you should also have test fixtures in place: They can validate that your refactorings don't change the behavior of your software."

http://en.wikipedia.org/wiki/Refactoring

AVK>Теперь вернемся к тестам. По идее, согласно заветам классиков TDD, юнит тесты самое оно для рефакторинга. Но вот ведь незадача — любой мало мальски сложный рефакторинг гарантированно ломает тесты.

Значит плохо перерефакторили. Это они и ловят.

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


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

IMHO, UT и любые другие бесполезны когда происходит перепроектирование, и это OK. Единственные проблемы, которое это создает — это нарушание одного из инвариантов TDD, не пишем кода если не падает тест из-за чего и получаем битое test-coverage. Но это можно побороть другими методами если нужно.

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

Но без знания конкретного случая рецепты давать сложно: какова стоимость написания теста, почему она такая? Какая test strategy (что и как мы будем тестировать, как сделать так чтобы потратить мало но сделать (уменьшить риски) много, где ручками, functional or unit-test, где UI, где BLL а где libs/utilities.), как делается test coverage analysis и какая policy на изменение покрытия.
IMHO, возможно использовать тесты, так чтобы работа ускорилась.


AVK>P.S. По свидетельству знакомых, занимающихся тестированием профессионально, долго и успешно, стоимость хорошего покрытия тестами проекта составляет от 25 до 40 процентов от стоимости разработки того, что тестируют, в случае, если проект неплохо подходит для модульного тестирования. Если подходит плохо, то цифра может быть и 100%. Циферки заставляют задуматься, не правда ли?

Да нет, честно говоря не заставляет, потому что информации мало. Какого проекта? Какими тестами? К 100%? Да легко — я думаю что в MS (чтобы недалеко ходить) на некоторых проектах намного больще.

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

M>

M>Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior. Neil Roodyn recommends that "if you refactor, you should also have test fixtures in place: They can validate that your refactorings don't change the behavior of your software."

http://en.wikipedia.org/wiki/Refactoring

Думаешь, я этого не знал? Вопрос только в одном — на каком уровне мы фиксируем этот meaning or behavior. Далеко не факт, что на том же, на котором оперируют юнит-тесты.
Попробую объяснить более понятно. Пусть есть у нас некая система А, meaning&behavior которой определяются требованиями заказкика (замечу, тоже в довольно зыбких рамках, куда более зыбких, нежели формализм unit tests, ну да не суть). Система А состоит из компонентов В и С. На каждый из которых, разумеется, есть свои спецификации, проистекающие из требований заказчика, но уже в значительной степени определяемых и разработчиком. И на каждый компонент имеется достаточный набор тестов. Теперь, ввиду найденой ошибки, либо еще каких внутренних причин, но нам понадобилось существенно изменить код компонента В без сохранения M&B. При этом контракт В существенно меняется, однако набор требований к А не меняется. Является ли эта операция рефакторингом по отношению к В. Согласно приведенному тобой определению (хотя мне оно кажется неполным, но об этом чуть ниже) нет. А является ли это рефакторингом по отношению к А? Да, является, поскольку поведение системы в целом не изменилось, несмотря на изменение поведения одного из компонентов.
Теперь о том, почему это определение мне не нравится. Не нравится оно мне, потому что оно слишком узко. Мне так кажется, что балансировка в пределах нечетко очерченных рамок требований (а оно, как правило, так и есть) вполне отвечает духу понятия рефакторинга, а юнит-тесты в качестве способа, контроллирующего эти рамки, слишком формальны и прямолинейны. В конце концов, требования определяются человеком и утверждать, что их всегда заранее и на 100% выразить ввиде программного кода несколько самонадеянно, не находишь? А коль так, то юнит-тесты вполне имеют право эволюционировать в процессе разработки продукта.

AVK>>Теперь вернемся к тестам. По идее, согласно заветам классиков TDD, юнит тесты самое оно для рефакторинга. Но вот ведь незадача — любой мало мальски сложный рефакторинг гарантированно ломает тесты.

M>Значит плохо перерефакторили. Это они и ловят.

Да нет, не плохо. Прорефакторили хорошо. Но рефакторинг, который не затрагивает вобще ни одного публичного контракта, это слишком примитивный рефакторинг. Масса видов рефакторинга, наличествующего в распространенных средствах автоматизированного рефакторинга и описанных тем же Фаулером ломает контракт если не гарантированно, то очень часто. А коль так, то и юнит-тесты, завязанные на этот контракт, гарантированно будут сломаны. В лучшем случае тесты просто перестанут компилироваться. А в худшем нам придется тесты отлаживать.

M>Вы наверное имели в виду не рафакторинг, а просто переписывание кода.

Да назови как хочешь. Главное, что в этом случае тесты конкретно начинают мешать.

M>IMHO, UT и любые другие бесполезны когда происходит перепроектирование, и это OK.

Да, но как быть с TDD, предписывающим начинать проектирование с тестов? Что, писать по новой новый набор тестов при каждом редизайне? Это ж застрелиться просто! Писать тесты после того, как редизайн станет маловероятным в ближайшее время? Но это идет в разрез с принципами TDD.

M>Но это можно побороть другими методами если нужно.

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

M>Но без знания конкретного случая рецепты давать сложно: какова стоимость написания теста,

Тебе в чем, в шекелях?

M> почему она такая?

Интересный вопрос. Сродни — почему на небе звезды.

M> Какая test strategy (что и как мы будем тестировать,

Разрабатываемый продукт при помощи модульного тестирования.

M> как сделать так чтобы потратить мало но сделать (уменьшить риски) много,

То есть как побороться с граблями, которые только что самостоятельно заботливо прикопал. Может проще грабли не прикапывать?

M> где ручками, functional or unit-test,

Здесь о UT вобще то топик. С функциональным тестированием все просто — оно должно быть. От него не уйдешь никаким боком.

M>как делается test coverage analysis и какая policy на изменение покрытия.

Это все только увеличивает стоимость тестов. А она и так черезмерна.

M>IMHO, возможно использовать тесты, так чтобы работа ускорилась.

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

M>Да нет, честно говоря не заставляет, потому что информации мало. Какого проекта?

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

M> Какими тестами?

Модульными в основном.

M>К 100%? Да легко — я думаю что в MS (чтобы недалеко ходить) на некоторых проектах намного больще.

Вот. Думаю не надо говорить, что подобные затраты приемлемы не для любых проектов и не для любых фирм?

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

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

DG>>я ответил.
DG>>могу ответить более определенно — не знаю.

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

E>Давайте доведем ситуацию до маразма:

А зачем до маразма ? Критерий кажется совершенно ясен , если проверка оставленная в коде не ухудшит качество программы , значит оставить , иначе не оставлять.

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

FDS>То есть для этого нам нужна уже готовая правильно работающая программа. Такие ЮТ могут найти ошибку только при изменении программы, но не при её первичной отладке. Надеюсь, это очевидно.
Гм. А как ты получаешь правильно работающую программу? Я вот обычно запускаю ее и смотрю на результат. Частенько в первый раз запускаю под дебаггером, чтобы убедиться, что алгоритм работает именно так, как я предусмотрел. Значительно реже я включаю трассировку.
Так что предложенный способ сам по себе мне очень нравится:
1. Пишем первичную версию, запускаем ее на каких-нибудь тестовых данных и смотрим в output. Если нас не устраивает этот output, мы правим программу. Повторяем до полного удовлетворения . (Обращаю внимание, что на этой фазе output педантично вычитывается). Коммит.
2. Обнаружив некоторый баг, придумываем новый набор входных данных, на которых он воспроизводится. Чиним код, чтобы и в этом случае получался корректный output #2. Простым сранвненим убеждаемся, что output #1 не сломался. Если оказывается, что новый результат тоже корректен (например, мы немного подправили условия задачи, или где-то нам неважен порядок вывода), то мы коммитим новый output #1.


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

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

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

AVK>Да, но как быть с TDD, предписывающим начинать проектирование с тестов? Что, писать по новой новый набор тестов при каждом редизайне?

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

AVK>Это ж застрелиться просто! Писать тесты после того, как редизайн станет маловероятным в ближайшее время? Но это идет в разрез с принципами TDD.

Можно и так — это часть testing strategy.

[...]

M>>Но без знания конкретного случая рецепты давать сложно: какова стоимость написания теста,

AVK>Тебе в чем, в шекелях?

Мне было бы интересно узнать хотя бы субъективную оценку — для типичного модуля в проекте, сколько в результате имееем тестов и сколько времени тратиться на разработку среднего теста (в часах) — желательно сколько на дизайн и сколько на реализацию и показать типичный тест конечно.

M>> Какая test strategy (что и как мы будем тестировать,

AVK>Разрабатываемый продукт при помощи модульного тестирования.

Это не кажется мне хорошей test-strategy. Все будем так тестировать? И GUI? Все контуры продукта по 100% test coverage?

AVK>Здесь о UT вобще то топик. С функциональным тестированием все просто — оно должно быть. От него не уйдешь никаким боком.

А уже сошлись на том что такое UT? А то ветка большая, вроде я много прочел, но может что пропустил? Вот если мой тест не "exercises a single class in isolation of all others.", то эта ветка не о нем?

M>>как делается test coverage analysis и какая policy на изменение покрытия.

[...]

M>>Да нет, честно говоря не заставляет, потому что информации мало. Какого проекта?

AVK>В среднем по проектам, которые приходилось конторе, в которой работает товарищ, тестировать. Контора, как ты уже наверное догадался, аутсорсит тестовые услуги.

Нет — не догадался.

[...]

M>>К 100%? Да легко — я думаю что в MS (чтобы недалеко ходить) на некоторых проектах намного больще.

AVK>Вот. Думаю не надо говорить, что подобные затраты приемлемы не для любых проектов и не для любых фирм?

Наверное, я за все компании отвечать не берусь. У нас это наверное было бы чересчур, но не очень намного, если так по простому посчитать — 1 SDET на 1 SDE — это значит что минимум 100% стоимости разработки это тестирование.

Здравствуйте, WolfHound, Вы писали:
WH>Я вобще не адепт TDD и мне нужны тесты не для того чтобы проверить корректность программы, а для того чтобы они показали что что-то изменилось.
Слушай, а как ты отличаешь настоящие изменения от таймстэмпов? У меня TortoiseSVN меняет иконку у всех перезаписанных файлов, даже если контент совсем не изменился.

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

M>А зачем до маразма ? Критерий кажется совершенно ясен , если проверка оставленная в коде не ухудшит качество программы , значит оставить , иначе не оставлять.

Ага, только как понять: ухудщит она или нет

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

GZ>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>>... о срочных проектах.
GZ>Тута есть еще одна штука. Если брать классические процессы, и это не система сделанная на коленке, то обычно действует правило 40-20-40, где 40 процентов времени занимет постановка, 20 программирование, и 40 процентов тестирование и отладка. Юнит-тесты могут сократить последнюю цифру.

Ты забыл кое о чем. Кроме того что они могут уменьшить последнюю цифру, они могут увеличить вторую и увеличить третью (тесты ведь тоже надо отлаживать).

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

S>Здравствуйте, WolfHound, Вы писали:
WH>>Я вобще не адепт TDD и мне нужны тесты не для того чтобы проверить корректность программы, а для того чтобы они показали что что-то изменилось.
S>Слушай, а как ты отличаешь настоящие изменения от таймстэмпов? У меня TortoiseSVN меняет иконку у всех перезаписанных файлов, даже если контент совсем не изменился.

Кстати да, интересно. У меня TortoiseSVN то же так делает (вчера проверил)

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

C>Юнит-тесты как раз повзоляют это выловить и по
C>горячим следам тут же исправить.

Позволяют выловить сколько процентов?

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

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

FDS>>То есть для этого нам нужна уже готовая правильно работающая программа. Такие ЮТ могут найти ошибку только при изменении программы, но не при её первичной отладке. Надеюсь, это очевидно.
S>Гм. А как ты получаешь правильно работающую программу? Я вот обычно запускаю ее и смотрю на результат. Частенько в первый раз запускаю под дебаггером, чтобы убедиться, что алгоритм работает именно так, как я предусмотрел. Значительно реже я включаю трассировку.
S>Так что предложенный способ сам по себе мне очень нравится:
S>1. Пишем первичную версию, запускаем ее на каких-нибудь тестовых данных и смотрим в output. Если нас не устраивает этот output, мы правим программу. Повторяем до полного удовлетворения . (Обращаю внимание, что на этой фазе output педантично вычитывается). Коммит.
S>2. Обнаружив некоторый баг, придумываем новый набор входных данных, на которых он воспроизводится. Чиним код, чтобы и в этом случае получался корректный output #2. Простым сранвненим убеждаемся, что output #1 не сломался. Если оказывается, что новый результат тоже корректен (например, мы немного подправили условия задачи, или где-то нам неважен порядок вывода), то мы коммитим новый output #1.


S>Смысл замечательный — нам не надо отдельно описывать корректные результаты. Мы всего лишь фиксируем поведение программы на некоторый момент времени. Это может даже быть неправильное поведение. Но это позволяет отловить регрессию, а она и есть бич всех изменений. У нас нет точной статистики, но интуитивно все более значительная часть времени уходит на отлов именно регрессионных багов.


Да я не спорю. Просто у человека всё слишком легко получалось по его словам.

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

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

FDS>>Ну дак, опят же, может разработчик не strlen проверяет, а сразу целый набор функций.

IT>Ты бы проверял strlen в отдельности или в купе с целым набором функций?

Лично я практически всегда проверяю сразу комплекс функций. По одной мне всегда лень...

P.S. Тем более что я иногда просто не в состоянии понять, какой результат отдельной функции правильный, а какой нет.

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


M>>>К 100%? Да легко — я думаю что в MS (чтобы недалеко ходить) на некоторых проектах намного больще.

AVK>>Вот. Думаю не надо говорить, что подобные затраты приемлемы не для любых проектов и не для любых фирм?

M>Наверное, я за все компании отвечать не берусь. У нас это наверное было бы чересчур, но не очень намного, если так по простому посчитать — 1 SDET на 1 SDE — это значит что минимум 100% стоимости разработки это тестирование.


Я понимаю, что в пылу сражения забыли про то, что стоимость разработки ПО есть сумма не только стоимости кодирования и тестирования. Но вот что тестирование составляет 100% всей стоимости — это мне понравилось. Наверное, речь шла о 50%? Т.е. стоимость кодирования == стоимость тестирования

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

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

S>>Здравствуйте, WolfHound, Вы писали:
WH>>>Я вобще не адепт TDD и мне нужны тесты не для того чтобы проверить корректность программы, а для того чтобы они показали что что-то изменилось.
S>>Слушай, а как ты отличаешь настоящие изменения от таймстэмпов? У меня TortoiseSVN меняет иконку у всех перезаписанных файлов, даже если контент совсем не изменился.

FDS>Кстати да, интересно. У меня TortoiseSVN то же так делает (вчера проверил)

всё равно все ваши такие решения временные
только специализированные решения вроде http://www.sourceforge.net/projects/izh-test/
способны обеспечить полное удобство:

— межкоммитную разработку (так как ждя приёмки эталонов их не надо коммитить)
— выборочный запуск тестов (только тех которые нужны в данный момент для отладки — проблемных)
— быстрый вывод и эталона и результата в том числе и в броузере как документа
— возможность встраивания в систему CruiseControl-я специальной консольной утилиты

кароче мне нужен квалифицированный feedback и контрибуторы!

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


DG>Возьмем ранее упоминавшийся графический движок — если он будет для каждого 100-го кадра в background-е проверять правильность вывода, через тот же более простой, но более медленный алгоритм, то ничего страшного не случится.

Аналогия придумалась. Допустим, в managed языках (Java, C#, Nemerle, Python, Ruby, ...) корректность индекса при обращении к элементу массива проверяется не при каждом обращении, а только при каждом сотом.

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