Re[2]: Как важно проверять в программах ошибки до конца - О жизни

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

D>Здравствуйте, мыщъх, Вы писали:
М>> программист, который писал функцию факториала был не в курсе что такое факториал вообще и очень сильно удивился, когда _все_ калькуляторы считали факториалы дробных чисел. программист сказал, что они все идиоты и едут по встречной, а он находится в своем ряду.
D>А можно для тупых поподробней. Я всегда считал, что факториал определён только для целых неотрицательных чисел. Гамма функция это какбы не совсем факториал.

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

#define E 2.71828182845904523536
#define PI 3.14159265358979323846

// stirling's formula
double gamma_fun(double x) { return sqrt(2.0 * PI/x) * pow(x/E, x); }
double factorial(double x) { return gamma_fun( x + 1); }

возьмите факториал от дроби и сравните с виндовым калькулятором. ну или с любым он-лайн калькулятором (вдруг это ошибка виндового калькулятора), вот первая ссылка в гугле: http://www.calculator-tab.com/

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

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

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

M>Я иногда кое-что пишу или отлаживаю на Delphi или FreePascal (не только на них и вообще это не так важно). Сегодня отлаживал одну ошибку, программа почему-то падала. Выяснил, что падение возникает из-за ошибок в некоторых данных (это другая история), которые программа забывала проверить на корректность. Добавил проверку. Можно было бы успокоиться, что все заработало, но решил выяснить, из-за чего она все-таки падала при неправильных данных.

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)

M>Мораль в качестве выводов:

M>1) Если есть ошибка полезно докопаться до ее истоков, а не просто избавиться от нее.
M>2) Можно обнаружить что-то для себя новое в казалось бы давно и хорошо известном.

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

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

L>Здравствуйте, мыщъх, Вы писали:

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

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

так ведь отвалится. и сейчас я объясню почему.

L>unsigned long factorial(int n)
L>{
L> static const unsigned long fact_tab[13] = {
L> 1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800, 39916800, 479001600
L> };
L>Вариант безглючный и самотестирующийся.

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

но даже если исходить из допущения, что оптимизация не влечет потерю точности, то у вас таблица все равно не правильная. ну ладно, заполняли от балды. бывает. меня вот что интересует -- с каких это пор размер int'а стал строго определенным? или вы никогда не писали программу под 2+ платформы сразу? если int у нас 64 бита (а такое возможно), то тут нужно сначала посмотреть какой у нас int на данной конкретной платформе, а уже потом выбирать под него таблицу. а если int 16 бит (такое тоже бывает), то ваш тест снова выстрелит мимо.

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

> Если понадобится факториал дабла, отрицательных чисел, натуральных дробей, и.т.д,
> то буду делать по учебнику, применяя подходящие к случаю типы данных.
пытаюсь объяснить еще раз. в реальной жизни куча функций типа факториала считается приближенно, ибо точный результат зачастую менее важен, чем скорость вычислений. проблема даже не в том, чтобы вычислить 100000! (можно и по таблице), проблема в том -- как хранить такой большой bignum и что с ним делать.

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

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

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

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

Здравствуйте, мыщъх, Вы писали:

М>>>а вы тесты писали? насколько серьезно подходили к процессу их разработки?
L>>Почему в прошедшем времени?
М>потому что русский язык такой. в английском было бы Present Perfect Tense --> опыт есть: да/нет

Двойка тебе. Как по русскому, так и по английскому. В контексте обсуждения на русском нужно использовать настоящее "вы тесте пишете?", а на английском present continous "are you writing unit tests (at all)?".

L>>Остальное поскипано как очередная история очередного ниасилинга
L>>с кучей оправданий одно другого убедительнее. Обсуждения не заслуживает.
М>а вы осилите тест факториала? хотя бы на уровне псевдокода? если да, то почему вы не миллионер?

При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь. Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину твоего заблуждения, и считаю, что будет просто честным предложить оставаться тебе в своем хакерском R&D мире и не лезть в инженерные задачи в своих латексных перчатках. У нас требуются сертифицированные перчатки другой системы, и несоблюдение техники безопасности бывает фатальным.

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

Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time. Его можно тестировать, но смысла особого нет. Но и твою притянутую за уши реализацию гамма-функции я тоже протестирую, но при одном условии — если ты асилишь обозначить четкие критерии ее использования в программе, ее предназначение, ограничения и ожидаемое поведение. Если этого нет, то разочарую тебя — прикладной аналитикой занимаются на другом этаже.

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

CL>объясните идиоту, пожалуйста,
CL>как можно использовать try...finally и не знать как оно работает?

Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.

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

L> Написать тест, проверяющий поведение его супер-функции при корректных, некорректных и граничных вхожных данных заняло бы две минуты. Ладно, это у меня. У ТС — ну полчаса максимум. Сколько у него там на отладку ушло времени? Вот то-то и оно.

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

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

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

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

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

L>Здравствуйте, мыщъх, Вы писали:

М>>потому что русский язык такой. в английском было бы Present Perfect Tense --> опыт есть: да/нет
L>Двойка тебе. Как по русскому, так и по английскому. В контексте обсуждения на русском нужно
L>использовать настоящее "вы тесте пишете?", а на английском present continous
L>"are you writing unit tests (at all)?".
единица вам. "are you writing..." вы пишите тест _одновременно_ с чтением форума. вы юлий цезарь?
Present Perfect Tense переводится как "вы _когда_ _либо_ писали тесты?". по аналогии I've been in London. это отличается от I was in London. в первом случае это "у меня есть жизненный опыт и я знаю что такое Лондон не только по картинкам", во втором случае вы просто там были. например, вас спрашивают -- какого хрена вас вчера не было на рабочем месте. а вы отвечаете: I was in London.

L> При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь.
L> Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину
с критическими инфраструктурами я не сталкивался и как там тестируют по — хз, но энерпрайз и военка -- это для меня ежедневная рутина. показывать им юнит тесты все равно что показывать палец. юмора не поймут и слив защитан.

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

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

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

L> Списывание отсутствия тестов на недостаточность ресурсов — это безоговорочное
L> признание в собственной некомпетентности и прямая путевка за кассу в Макдональдс.
пытаюсь объяснить еще раз -- сложность _полного_ теста намного превышает сложность того, что мы тестируем. откроейте глаза и посмотрите на то, что вас окружает. начиная с программного обеспечения и заканчивая медикаментами. далеко не все это тестируется, а если и тестируется, то неполно и поверхностно. ракетно-космическая техника тестируется лучше, чем гражданская авиация, а гражданская авиация тестируется лучше, чем бытовой софт. а если бытовой софт тестировать по полной программе, то это все равно не гарантирует отсутствие ошибок, но цена ms office перевалит за миллиард баксов за одну лицензию. что вы курили?

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

L> Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time.
см. определение из вики. см. функцию факториала из гну либы на gcc.

L> Его можно тестировать, но смысла особого нет.
поздравляю. вы произнесли заветные слова. "тестировать можно, но на хрена?". то есть по факту вы со мной согласны, но при этом делаете вид, что один из нас дурак, хотя мы оба говорим, что юнит-тест написать можно, но смысла в этом нет.

L> Но и твою притянутую за уши реализацию гамма-функции я тоже протестирую,
она не моя. она из 18 века вообще-то. а сейчас 21 век. столько не живут ИМХО.

L> но при одном условии — если ты асилишь обозначить четкие критерии ее использования в программе,
лопата! вот у вас есть библиотечная гамма-функция. а она у вас есть (если под никсы пишите). и у вас возникает вопрос -- как быстро она работает? насколько сильно ошибается? вы хотите знать подходит ли она вам или нет. у вас есть требования по точности и времени. известны и целевые платформы. дело за малым -- убедиться, что все воркается. и вот тут выясняется, что тестирование функции которая заведово работает выливается в сложную инженерную задачу...

L> Если этого нет, то разочарую тебя — прикладной аналитикой занимаются на другом этаже.
вот он -- момент просветления. на уровне юнит-теста вы не можете сказать какие у вас требования к данной функции. допустим, время отклика системы должно быть не хуже 15 ms на таком-то железе. это во всей совокупности.

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

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

CL>>объясните идиоту, пожалуйста,
CL>>как можно использовать try...finally и не знать как оно работает?
A>Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.
проблема несколько глубже. результаты уже на лице -- в жабе стало нельзя легально прибивать потоки без участия с их стороны. допустим, мы вызвали скрипт манагер из жабы, который вызывает жаба-скрипт, контролируемый юзером/хакером. допустим, в жаба-скрипте while(1); -- в результате поток висит. легально снять -- нельзя. нелегально можно, но это уже хак.

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

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

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

короче, лучше не использовать конструкции языка, которых не знаешь.

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

L>Здравствуйте, мыщъх, Вы писали:

L>При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь. Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину твоего заблуждения, и считаю, что будет просто честным предложить оставаться тебе в своем хакерском R&D мире и не лезть в инженерные задачи в своих латексных перчатках. У нас требуются сертифицированные перчатки другой системы, и несоблюдение техники безопасности бывает фатальным.

Мне, на самом деле, давно интересно собрать статистику, сколько раз regression unit tests вылавливало ошибки, сколько раз после успешного тестирования ошибки все равно обнаруживались и сколько раз test failures ловили ошибки кода, а не теста.

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

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

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

Это наблюдения из практики как она есть — никаких теорий.

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

D>>>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
D>>>сорри, ниче личного, но это реально факт.

HS>>Знаете, ничего личного, но, например, я, с высоты 11+-летнего опыта промышленной разработки на целой куче императивных языков, не вижу принципиальной разницы между дельфи, крестиками, джавой, шарпом, и чем-бы то ни было ещё императивным.

D>между тем она есть. и даже не в самом языке дело.

Вот видите! Не в языке.

D>дельфи создает иллюзию простоты,

Там не иллюзия простоты, там (на момент конца 90-х и начала нулевых) -- неиллюзорная простота разработки нативных оконных приложений под Windows.
Microsoft к такой простоте формоклепания пришёл значительно позже. Значительно. Если вообще пришёл.

То, что в системе язык-библиотека-среда программирования есть простота -- это плохо?

D>там низкий порог вхождения,

1. Это плохо?
2. Там, между тем, гораздо проще выстрелить себе в ногу, чем, например, в C#. Не в этом дело.

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

В самом верху не ваша ли цитата? У вас там квантор всеобщности стоит.

D>лет 10 назад мне довелось отсмотреть кучу (больше сотни) мелких проектов, сделанных разными людьми; больше половины из них на дельфи.

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

D>статистика однозначная — сделанное на дельфи очень сильно проигрывает тому же С++.

О дааа. Предлагаю сравнить VCL, сделанную людьми и для людей на дельфи, и MFC, которую, видимо, завезли с Марса. Такое о ней, во всяком случае, сложилось впечатление.
Впрочем, нет. Не предлагаю. Холивар уже разгорается, а в спец. олимпиадах мне участвовать неинтересно.

Сама IDE Delphi написана на Delphi, и уж что-что, а формочки клепать на ней куда как удобнее, чем в VS. То есть, по крайней мере по параметру удобства клепания формочек (==проектированию и программированию оконного интерфейса), дельфи впереди VS. И что теперь?

Впрочем, должен сказать, что Delphi я не видел уже лет шесть. Говорят, там есть новые плюшки типа дженериков и перегрузки операторов, но это я не в курсе. Ибо если ты работаешь с железом и пишешь дрова, выбора, на чём писать, у тебя нет.

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

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

N>

N>for i:=0 to 7 do
N> ...
N>

N>i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

Т.е. цикл итерируется больше 8-ми раз? Такого не встречал.. А вот по поводу "i" после цикла, помню что в таком коде в турбо-паскале она бы равнялась 7-ми, что исключало возможность использовать её значение. В Delphi, вроде как, ситуацию исправили, но при попытке использования выдаётся warning...

Здравствуйте, linuz, Вы писали:
L> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

А нечего было так глубоко залазить

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

SUA>Здравствуйте, linuz, Вы писали:
L>> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

SUA>А нечего было так глубоко залазить

То есть, чтобы не использовать goto теперь надо еще и от вложенных циклов отказаться?

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

CL>>объясните идиоту, пожалуйста,
CL>>как можно использовать try...finally и не знать как оно работает?

A>Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.

Ну, в доках явы, скажем, все описано в паре строчек:

The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.

http://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html

И эта ссылка первая по запросу "java finally". Так что можно прочитать только два первых предложения, чтобы понять суть.

Случаи с прерыванием потока или всего предложения описаны еще двумя предложениями ниже.

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

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

L>>Здравствуйте, мыщъх, Вы писали:

F> Мне, на самом деле, давно интересно собрать статистику, сколько раз regression unit tests вылавливало ошибки,
F> сколько раз после успешного тестирования ошибки все равно обнаруживались и сколько раз test failures
F> ловили ошибки кода, а не теста.
зачем ее собирать, когда она и так есть? http://www.cvedetails.com/ -- пища для размышлений. и ведь во всех этих компаниях есть целые подразделения, занимающиеся исключительно тестированием с нехилым таким бюджетом. а что на выходе? _абсолютно_ _ничего_ работающего хотя бы на 90%. это не значит, что тесты бесполезны. это значит, что на практике ошибки приходится фиксить _после_ релиза на стадии пуско-наладки. причем, эта вполне законная стадия, которой не избежал ни один проект.

F> В практике я ни разу еще не видел, чтобы это работало.
+500. товарищ привел тест, неявно подразумевающий, что у него int 32 бита. очень "полезный" тест, да.
даже если не брать факториал ( это все-таки матчасть ), а взять функцию сортировки, то даже в этом случае трудоемкость написания теста и его объем раз в сто больше. следовательно, в сто раз больше вероятность допустить ошибку в тесте.

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

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

> Создание хороших тестов работа более трудозатратная, сложная и высококвалифицированная
> нежели создание самого кода для бизнес логики. Но даже с хорошими тестами все равно
> ошибки возможны. И затраты на поддержание онных достаточно велики.
в том-то и дело, что написать парсер, скажем, XML раз в 100500 раз проще, чем написать тест этого парсера. в обоих случаях требуются глубокие знания XML. если их нет, то парсер написать еще можно и он будет как бы работать, а вот написать для него тест и _доказать_ полноту теста -- это высший пилотаж. и на практике применяется другой подход. берут "живые" данные и смотрят на реакцию парсера. если на каком-то файле парсер падает -- юзер сабмитит этот файл в саппорт и там уже разбираются. это -- реальная жизнь.

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

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

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

F>Это наблюдения из практики как она есть — никаких теорий.
в том-то и дело, что тесты -- не панацея. а юнит тесты это как целые числа на фоне всех прочих. и гордится тем, что у нас есть юнит тесты это все равно, что говорить "а я умею считать до ста тысяч миллионов".

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

тут кончается теория и начинается реальная жизнь. тест XML парсера, написанный по науке -- бесполезен, ибо парсер падает на "живых" данных, о которых тест и не подозревает. и в чем ценность такого теста? а если взять программу на JavaScript, то как ее тестировать юнит-тестами, если нам нужно, чтобы она нормально работала на всех браузерах? тестировать -- нужно. но не юнит тестами.

в реальной жизни основная нагрузка ложится на QA. они, в частности, проверяют, что в коде нет ошибок типа SQL-injection и вообще тестируют все, что только можно протестировать. а если у нас есть QA, то зачем вкладываться в юнит-тесты? да, конечно, юнит тесты бывают полезны местами, чтобы отлавливать наиболее грубые ошибки. но тут главное не перестараться и не вложить в юнит тест больше времени и сил чем нужно.

	От:	Eugeny__
	Дата:	20.06.12 10:55
	Оценка:

	От:	carpenter
	Дата:	20.06.12 11:00
	Оценка:

От:	Vladek	Github
Дата:	20.06.12 11:16
Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	20.06.12 12:23
Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	20.06.12 12:42
Оценка:	1 (1)

	От:	SingleUseAccount
	Дата:	20.06.12 19:42
	Оценка: