Здравствуйте, landerhigh, Вы писали:
M>>Тогда немного опишу, что же именно некорректного было в данных. У меня функция заносит в БД извлеченное и обработанное содержимое некоторых файлов внутри *.zip -файлов, при этом естественно проверяет на корректность и само содержимое обрабатываемых файлов и формат и тд. При этом в редких случаях внутри *.zip-файла может быть еще вложенные *.zip-файлы и их тоже надо распаковать и в свою очередь проверить, что внутри. Вложенный файл я обрабатывал просто рекурсивным вызовом.
L>Ой, уже звучит страшно. Не слишком ли много для одной функции? Хотя, если она внутри выглядит примерно так
Это не одна функция — это одна программка, которая написано мной полностью и никем, кроме меня же не протестирована
L>то все еще пучком.
M>>Тесты (просто набор разных исходных данных) есть, все ситуации с ошибками тестировали и они обрабатывались, программа не падала.
L>Не все. Не удивлюсь, если знаменитая mail-бомба в зипе также способна свалить вашу программу. Да тут еще и рекурсия, подуснет какой дятел поврежденный или специально подготовленный зип с тучей уровней вложенности и привет переполнение стека.
Не проверял на mail-бомбы, собственно если внешняя либа ей подвержена то будет плохо, если нет — просто ошибка вернется. Но это все-таки, утилита для внутренней автоматизации, которую я быстро написал и с год не прикасался к ней, а не серьезный программный продукт.
M>> Но забыли протестировать случай, когда такая ошибка возникает при работе с содержимым внутри вложенного файла. То есть, неправильная работа с exit не приводила почему-то к падениям, пока работа шла на первом уровне вложенности. Я и говорю, что диспетчер памяти оказался склонным прощать некоторые ошибки в работе с ней. Падать стало внутри рекурсии.
L>привычка писать юнит-тесты доводит до того, что программист органически становится неспособным "забыть" протестировать такие. То есть написать тест, покрывающий подобную ситуацию воспринимается как нечто само собой разумеющееся и никаких вопросов не вызывает. L>Кроме того, написать юнит-тест, проверяющий корректность работы и непадучесть этой функции, примерно в 10 тысяч раз легче, нежели тестировать ее корректное поведение на этапе QA. И выгоднее.
Кхм, но вот я ее проверил на обработку ошибок в данных, на обработку вложенных zip-ов, а вот на комплекс, когда и ошибка в данных и данные внутри вложенного zip-а — не догадался, не подумал. По отдельности-то все работало. Более того, ошибки в данных и вообще очень редко встречаются, а такое их сочетание и вовсе вылезло только через год.
M>>Программу я уже не трогал с год, просто все это время не случалось такого редкого сочетания с ошибкой.
L>А сколько еще подобных мест в вашем коде?
Да наверное хватает Просто цели по качеству сверх минимально необходимого не ставилось. Собственно, если бы не мое же заблуждение насчет exit() ошибки бы в итоге и не возникло.
Re[6]: Как важно проверять в программах ошибки до конца
Здравствуйте, Deprivator, Вы писали:
Q>>Однажды, очень давно, довелось мне написать это: Q>>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь. Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера. D>кстати да, абсолютно чудовищный код.
Еще один. Ладно, объясняю для тех, кто глухо в танке.
1. Этот код выдернут мной из клипперовского exe-шника.
2. Этот код является дословным переложением ассемблерного листинга на Delphi.
3. Сделано именно так для того, чтобы банковские крысы не придрались к реализации.
4. Где тут формошлепство, не подскажете?
И да, этот код, хоть и должен работать только в винде, но тем не менее он совершенно портабелен.
Re[2]: Как важно проверять в программах ошибки до конца
D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С D>сорри, ниче личного, но это реально факт.
Статья 29 Конституции Российской Федерации гласит, что
Не допускаются пропаганда или агитация, возбуждающие социальную, расовую, национальную или религиозную ненависть или вражду. Запрещается пропаганда социального, расового, национального, религиозного или языкового превосходства.
Make flame.politics Great Again!
Re[9]: Как важно проверять в программах ошибки до конца
М>так ведь отвалится. и сейчас я объясню почему.
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 бит (такое тоже бывает), то ваш тест снова выстрелит мимо.
Дорогой, на C++ фактораил считается в компайл-тайме при любом размере инта независимо от платформы. Поэтому его и оптимизировать никто не будет.
М>писать тест, который работает только в паре с определенным компилятором и под определенную платформу с определенными опциями компиляции -- на фига? вот перекомпилировали код и ваш тест показал ошибку. а ошибка не в коде, а в тесте. крысота.
Если ты умудришься написать для факториала тест, который работает только на определенном компиляторе под определнной платформой с определенным опциями, то сорвешь бурные продолжительные аплодисменты за самую бесполезную работу года.
М>это я не к тому, что юнит тесты не нужны. это я к тому, что сложность написания теста зачастую сильно превышает сложность написания кода. в вашем тесте больше ошибок, чем в коде. и этот тест создает проблемы на ровном месте, которые не возникают когда этого теста нет.
Еще раз — так говорят только некомпетентные товарищи. Хватит позориться.
Здравствуйте, landerhigh, Вы писали: L>Здравствуйте, b-3, Вы писали: b-3>>Здравствуйте, landerhigh, Вы писали: L>>>здесь. Дальше распространяться на эту тему не буду, но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты", потому что любое прошедшее время подразумевает, что тесты писали, b-3>>давно Present Perfect стало прошедшим? Present как переводится? L>Рассказать, как переводится Perfect? L>Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.
И всё же вы неправы — ваше present continious тоже не вполне корректно. Вот страница из очень авторитетной оксфордской грамматики, CGEL.
Cкан страницы
Цитирую:
Habitual progressive.
The professor types his own letters [The habit is permanent]
The professor is typing his own letters while his secretary is ill [The habit is temporary]
Поэтому "I'm writing unit tests" — это означает либо "я пишу в нынешнем проекте, а обычно не пишу" (a temporary habit), или "я прямо сейчас пишу тесты" (the current action).
Обратите также внимание на примечание внизу страницы(!) Там сказано, что наречие вроде always или all the time меняет смысл, поэтому "Are you always writing UT?" — будет понято правильно, а без always — не будет. Как и "Have you always been writing UT" имеет другой смысл, нежели "Have you been writing UT?". По сути, этот нюанс и разрешает ваш спор в пользу Касперского.
"Are you writing unit tests?" может в контексте иметь смысл habitual — например вопрос к подчинённому — "а юнит-тесты на свой код (который ты ещё не не закоммитил), ты пишешь-то?", но это довольно фамильярно. Вне контекста are you writing unit tests будет воспринято как event, т.е. вопрос о состоянии (ты сейчас что делаешь, пишешь юнит-тесты?) или о state, т.е. об должностных обязанностях (какова твоя роль в проекте, тесты пишешь?) — короче говоря, не поймут.
И надо помнить, что мыщъх вообще-то живёт в США и с native-ами общается изрядно, так что предлагаю постановку "единиц по инглишу" друг другу прекратить.
Забанен с формулировкой "клинический дисидент".
Re[2]: Как важно проверять в программах ошибки до конца
Здравствуйте, Deprivator, Вы писали: D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
Боюсь, что хуже только программисты на AutoHotkey.
Скрытый текст
Сам я не программист, но скрипты иногда здорово выручают. Недавно случайно обнаружил в AutoHotkey_L забавный глюк, о существовании которого даже не подозревал. Мне надо было копировать короткие текстовые строки, состоящие из 1-2 слов, одновременно преобразуя их так, чтобы первая буква в строке становилась заглавной, а все остальные — строчными. Думал использовать банальное решение: вырезаем первый символ и делаем его заглавным, а к нему присоединяем остальные символы, сделанные строчными. Не тут-то было! Как выяснилось, при конкатенации двух строк между ними почему-то вставляется лишний пробел. Пришлось добавить в конец скрипта операцию замены, чтобы убирать этот пробел.
Re[4]: Как важно проверять в программах ошибки до конца
Здравствуйте, landerhigh, Вы писали:
L>Тем, для кого юнит-тесты эквивалентны занятию ерундой, срочно рекомендуется сменить профессию. На сантехника или там развозчика пиццы. L>Других мнений по этому поводу быть не может.
От задачи таки зависит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Как важно проверять в программах ошибки до конца
Здравствуйте, landerhigh, Вы писали:
L>Почему же обидел? Просто за пропущенное юнит-тестирование (убедиться в отсутствии протечек) сантехник, в отличие от криворучки-программиста, может вполне получить неиллюзорных люлей непосредственно от заказчика и порой прямо не доходя до кассы. Отделаться сдавленными матами от коллег, которые потом придут это поддерживать, не выйдет.
при таком взгляде на работу сантехника мотивация смены специальности с программиста на сантехника как-то не просматривается? Или речь о мазохистах?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Как важно проверять в программах ошибки до конца
L>>Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.
b-3>И всё же вы неправы — ваше present continious тоже не вполне корректно. Вот страница из очень авторитетной оксфордской грамматики, CGEL.
В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом.
b-3>И надо помнить, что мыщъх вообще-то живёт в США и с native-ами общается изрядно, так что предлагаю постановку "единиц по инглишу" друг другу прекратить.
Никто его за язык не тянул. Он сам на инглиш перепрыгнул, да и кто из нас с ним больше с нейтивыми общается, вопрос тот еще
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
L>>Тем, для кого юнит-тесты эквивалентны занятию ерундой, срочно рекомендуется сменить профессию. На сантехника или там развозчика пиццы. L>>Других мнений по этому поводу быть не может.
E>От задачи таки зависит...
Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
L>>Почему же обидел? Просто за пропущенное юнит-тестирование (убедиться в отсутствии протечек) сантехник, в отличие от криворучки-программиста, может вполне получить неиллюзорных люлей непосредственно от заказчика и порой прямо не доходя до кассы. Отделаться сдавленными матами от коллег, которые потом придут это поддерживать, не выйдет.
E>при таком взгляде на работу сантехника мотивация смены специальности с программиста на сантехника как-то не просматривается? Или речь о мазохистах?
Позиция сантехника предлагается тем, кто еще не безнадежен и может учиться. Пару раз огребет, глядишь, и научится чему. Остальным же разучивать "свободная касса!"
Здравствуйте, landerhigh, Вы писали:
L>Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.
Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Как важно проверять в программах ошибки до конца
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
L>>Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.
E>Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...
Налицо непонимание концепции и предназначения юнит-тестирования. Объяснить или сам догадаешься?
Здравствуйте, Erop, Вы писали:
E>Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...
Можно конкретный пример, когда правильное поведение системы неизвестно?
Ce n'est que pour vous dire ce que je vous dis.
Re[8]: Как важно проверять в программах ошибки до конца
Здравствуйте, landerhigh, Вы писали:
L>Налицо непонимание концепции и предназначения юнит-тестирования. Объяснить или сам догадаешься?
Зачем догадываться до общеизвестных вещей?
Есть разные подходы к этому делу, но та секта, к которой принадлежишь ты, просто не умеет программировать иначе, чем с юнит-тестами. Просто адептом твоего направления для того, что бы спроектировать нормальный класс, нужно сначала написать для него тест, типа такая вот спецификация на код. В принципе подход, как подход, не лучше и не хуже других. Но он не единственный возможный, тем не менее.
Просто далеко не во всех программах и далеко не у всех специалистов основную трудоёмкость занимает именно кодирование и проектирование кода, ещё бывает разработка алгоритмов, построение данных всяких хитрых, настройка системы и т. д... И там юнит-тестирование мало полезно. Кроме того есть довольно много программистов, которым вообще не трудно написать какой-то код, основная стоимость разработки в таких проектах вообще не в кодировании сидит, а в других формах разработки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Как важно проверять в программах ошибки до конца
DR>Можно конкретный пример, когда правильное поведение системы неизвестно?
Ну торговля на бирже, например, или распознавание речи...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Как важно проверять в программах ошибки до конца
Здравствуйте, Erop, Вы писали:
DR>>Можно конкретный пример, когда правильное поведение системы неизвестно?
E>Ну торговля на бирже, например, или распознавание речи...
Это не конкретно, на таком уровне не составляют юнит тесты. Давай копнём один из этих примеров чуть глубже. Вбиваем в Google Scholar "speech recognition" и выбираем первую прикладную статью: "Minimum Prediction Residual Principle Applied to Speech Recognition". В ней реализуется распознавание слов по следующим шагам:
записывается слово
запись попускается через фильтр низких частот
результат дискретизируется
слово разбивается на части, и в каждой звук моделируется линейной комбинацией последовательных по времени сигналов
звучание любых двух слов сравнивается по линейным коэфициентам
Каждый шаг выполняет сторого определённую функцию, для каждого алгоритма известно правильное поведение.
Пропускаем через фильтр тестовый сигнал: смотрим, остались ли в нём высокие частоты. Пропускаем белый шум, пропускаем нулевой сигнал, итд.
Дискритизируем тестовый сигнал: смотрим, соответствует ли результат эталону.
Моделируем тестовый звук, проверяем точность модели.
Берём простые наборы тестовых коэффицентов, считаем дистанцию на калькуляторе, смотрим, соответствует ли алгоритм расчётам.
Ce n'est que pour vous dire ce que je vous dis.
Re[14]: Как важно проверять в программах ошибки до конца
Здравствуйте, landerhigh, Вы писали:
L>В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом.
Причудливым, т.е. непонятным вам?
L>Никто его за язык не тянул. Он сам на инглиш перепрыгнул, да и кто из нас с ним больше с нейтивыми общается, вопрос тот еще
Забанен с формулировкой "клинический дисидент".
Re[15]: Как важно проверять в программах ошибки до конца
Здравствуйте, b-3, Вы писали:
L>>В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом. b-3>Причудливым, т.е. непонятным вам?
Причудливым == не описанным в оксфордских словарях.
Это если на секундочку забыть о том, что разговорный английский порой довольно значительно отличается от английского "оксфордского".
Просто цели по качеству сверх минимально необходимого не ставилось. Собственно, если бы не мое же заблуждение насчет exit() ошибки бы в итоге и не возникло.
Present как переводится?
