Cyberax,
>> 2. Наш код — здесь возникает вопрос: откуда взялось неизвестное >> зацепление с кодом, который мы писали месяц назад? Вероятно мы >> наколбасили уже целых 10Мб и /основательно забыли и не записали о >> неочевидных условиях/, в которых работают классы из "первого" мегабайта >> и неявных связях между ними. C>Так ведь записывать ВСЕ неявные связи — невозможно. В моем примере C>неявная связь была в структуре одного из списков. Таких примеров у меня C>достаточно много.
Да, охотно верю, но нам не нужны ВСЕ связи, а только те, которые имеют значение и видны в конечном результате. Погоня за безупречным качеством обходится недёшево и требует совсем иного подхода, ежели у нас.
>> И теперь в новом классе мы создали нечто, >> что нарушило гармоничную работу тех классов... Не спорю, такое возможно. >> Но очень уж натянуто выглядит это... особенно для кода месячной давности. C>У меня такое достаточно часто бывает, особенно в командной работе.
C>Кстати, юнит-тесты еще в другом помогают — вот у нас есть модуль, C>который обрабатывает кучу вариантов. В моем случае это модуль, C>занимающийся раскрытием переменных: C>http://boost.sourceforge.net/boost-build2/doc/html/jam/language.html#jam.language.variables
C>В нем есть куча случаев и этот код, вдобавок, еще и является performance C>bottleneck'ом. При добавлении новой оптимизации нужно смотреть на то, C>что она не сломает какой-то частный случай. Без тестов это делать было C>бы оооочень жутко.
В данном случае бесспорно.
>> Наконец, если старые классы ломаются, то может быть это неважно? Важный >> код мы /всё-равно/ тронем, когда будем тестировать всё приложение. C>Вопрос в том когда оно обнаружится. Вдобавок, при работе в C>команде наведенные ошибки могут привести к тому, что отлаживать твой код C>будет уже другой человек и займет это у него больше времени (скорее всего).
Да, оно может обнаружиться на этапе тестирования пользователем или вообще у клиента. Увы, приходится мириться. Да, неприятно — поэтому уделяется большое внимание 100% проработке требуемых вариантов использования.
Джентельменские соглашения внутри команды исключают то, что править будет другой человек. А пройтись дебаггером по чужому коду — невелика проблема. На крайний случай, можно спросить: "Вася, а вот эти гирлянды ты зачем развесил?".
>> А написание тестов с нуля? C>В существующем проекте — скорее всего неоправдано.
Почему это?
>> Даже одновременно с кодом? Возможно, что (тесты + отладка >> < отладки), но определённо не в нашем случае. C>Опять же, случаи бывают разные. Но если код поддается юнит-тестированию, C>то оно обычно сокращает сроки разработки.
Ну вот о чём и речь. Мне кажется, что у вас условия работы и требования к коду совсем другие.
Andir,
A>Есть ещё такая метафора для юнит-тестирования как "проверка грамматических правил". Орфография в тексте проверяется фактом компилирования программы, а грамматика — покрывается правилами языка (тестами).
Кстати, гораздо чаще я эту метафору (spell-check) слышал применительно к статической типизации.
A>И затем если вставить куда-то в середину фразы дополнительные слова, то редактор в случае грамматически неверно построенных предложений подчеркнёт предложение и его можно как-то исправить, до тех пор пока ошибка не исчезнет. Вот только для кода нельзя построить список конкретных правил и этим занимается программист, а для письменности — это всё же возможно. Вот я грамматические ошибки в тексте очень не люблю . A>Ну а метафора, как и любая аналогия — неверна по определению
В принципе с мыслью согласен, и считаю что данная метафора вполне отражает суть вещей.
A>Для тестирования работоспособности программ существуют функциональные тесты, которые и правда могут быть заменены бригадой QA.
У нас примерно так и делается.
A>>> Отсюда и рождается болезненное восприятие изменения этого кода, потому как неизвестно как себя поведёт этот код при банальных изменениях в нём, а уж о сложных и говорить нечего, а тесты позволяют видеть как ведёт себя код при изменениях. LCR>>Свежий код меняется достаточно легко — мы его только что написали и помним все трещинки.
A>Угу, так как я часто пишу реализации алгоритмов (криптография в основном), то свежий код даже только что написанный не так то и легко запоминать по всем трещинкам. Особенно когда опасность его сломать заключается практически в любом изменении. На этом опыте просто хорошо очень это замечается, но я переношу это и на другие проекты, хотя там это не так заметно, и действительно, чтобы сломать только что написанный код в таких проектах нужно постараться.
Соглашения, архитектура и элементарная культура позволяют в принципе сносно управляться с изменениями в свежем коде. К тому же я не раз подчёркивал, что как только проект начинает "длиться во времени", то нужно уже делать тесты. Чем раньше, тем лучше, но очень рано не получается, потому что сначала есть более приоритетные задачи.
A>>>Тесты прежде всего нужны, чтобы было психологически легче изменять уже написанный код и удостоверятся, что при этом ничего не сломалось. Автоматический рефакторинг заменяет тесты при нефункциональных изменениях кода (то есть в средах, где автоматический рефакторинг отсутствует, уверенность работоспособности кода остаётся только на тестах). При функциональных же изменениях без тестов на работоспособность уже не обойтись. LCR>>Ты прав, и это не противоречит моим словам — в длительной перспективе тесты необходимы. Я же говорил о срочных проектах.
A>Понятие срочности очень растяжимое. Если "срочное" — это утилита, которая пишется два дня, выкидывается на использование и забывается, то конечно согласен, что тут тесты просто не успевают появиться (если конечно не используется методика TDD). Но если программа далее передаётся ещё и QA и затем наверняка возвращается для исправления ошибок, то, о каком же таком "срочном" проекте идёт речь?
2-3 месяца при функционале сравнимом скажем с оперой 5-й версии.
A>Еще, например я не пишу тестов для прототипов, потому как там действительно они только мешают быстро создавать эти самые прототипы.
+1, но о прототипах я даже не заикался (хотя я понимаю, что качество и наличие прототипирования очень сильно коррелируют).
A>P./S.: Напоследок ещё такое наблюдение: A>Отсутствие успешно отрабатывающих юнит-тестов говорит о халатности работы в команде, практически точно также как и коммит в репозиторий некомпилирующегося кода.
Аргх, опять догма. >:~(
A>C Уважением, Andir!
С уважением, LCR
borisman3,
B>Все. Написал бы больше, но нужно идти циферки складывать и денежки со счета на счет пересыпать... Большого Босса ублажать
Хотя я вот подумал, что как то звучит не хорошо (программисты предстают такими вечными мученниками и мальчиками на побегушках ). Можно ведь выразиться совсем иначе: "Большого Босса окучивать..." Здесь уже программисты предстают такими злыми гадами, издевающимися над бедной овечкой.
И то и другое конечно перегиб, истина как обычно по середине. (Где-то я натыкался на фразу, что коммерческое программирование — это сфера услуг, а услуги могут быть и высокоуровневыми, для IT в целом это так, имхо).
VD>2. Есть люди которые говорят как ты. Если высказаться более конкретно то это будет звучать так "Любые средства повышающие надежность кода хороши и полезны." При этом по хорошему надо добавлять "...если при этом они не создают проблем больше чем решают." LCR>>>Вдобавок, если юнит-тесты будут, то не будет (или будет в недостаточном количестве) чего-то другого. Как всегда, бесплатный сыр соблазнительно качается на пружинке... MR>>Не будет длительной отладки ? (шутка). На самом деле ты прав. Во всем важен баланс. Способсвует ли отсуствие или наличие ЮТ соблюдению баланса каждый отвечает сам. Ситуации они разные бывают.
Имелось ввиду именно это.
VD>Кстати, час Все же Фаулер довльно разумен и не столь радикален. Он продвигает многие средсвта повышающие качество кода. TDD только одно из них. Например, DSL-и он продвигает не хуже.
DSL имеют свою область применения. Точно так же как и TDD. Как я уже и говорил, для меня главное баланс. В той ситуации которую я описывал ЮТ показали себя с положительной стороны. Вопролен возможно что в другой команде или на другом проекте результат был бы другим. There is no silver bullet, как известно.
VD>Они используют юнит тесты для защиты, например, нетипизированных и опасных языков. В обсуждении тем связанных со статической типизации они постоянно принижают ее значения кивая на то что мол без юнит-тестов вообще не жить, а раз так то зачем тогда все эти проверки комиилятора. Все равно юнит-тесты все проверят.
Мне сложно говорить что-то относительно нетипизированных языков, поскольку дальше поверхностного изучения Scheme я не зашел ;( В целом я придерживаюсь мнения что использование типизированных и нетипизированных языков очень похоже на войну остроконечников и тупоконечников Свифта. Или споры о том чем удобнее кушать — китайскими палочками или вилкой. Человек пользуется тем, что ему удобнее. Одну и ту же задачу можно решить множеством способов, и не обязательно один из них заведомо лучше ИМХО... VD>Более того считаю что статическая типизация и безопасный язык даже более важны чем сами юнит тесты.
Опять же, все зависит от задачи имхо. Есть подозрение что существуют такие задачи которые с одинаковым успехом можно решить с статической типизацией и без нее. Вопрос в правильном применении инструмента. Лично я тоже склоняюсь к статической типизации, но это всего лишь вопрос предпочтения.
VD>Тесты проверяют динамику, а система типов статику.
+1
VD> Конечно юнит-тесты могут только помочь рефакторингу добавив контроля за ситуацией, но все же они не способны именно помочь и темболее автоматизировать рефакторин.
Собственно об автоматизации рефакторинга речь и не шла. Имелось ввиду именно контроль над ситуацией. Допустим при появлении студента в команде. VD> Те кто использует автоматизированный рефакторинг повседенвно так к нему привыкли, что даже незадумываются над тем, что их оппоненты не понимают этог, а стало быть оба лагеря недооценивают значимость автоматического рефакторинга.
Ну что тут можно сказать.. VS2005 рулит Но студия может обеспечить только синтаксическую и семантическую корректность. А когда при рефакторинге ломается логика, то получить максимально быстрый фидбек позволяют именно ЮТ имхо.
VD>Но даже если автоматический рефакторинг невозможен статическая типизация повзоляет существенно сократить объем работы и в особенности объем отладки, так как многие ошибки автоматически отлавливаются системой типов. При этом компилятор (особенно если он хороший) показывает места ошибок и содествует пониманию совершенной ошибки.
+1 Согласен на 100%. Но логические ошибки может отловить только человек. Ну или ЮТ написанные человеком. компилятор мало поможет если что-то поставит "+" вместо "-". Утрированно конечно, но тем не менее.
VD> Это намного лучше чем несработавший юнит-тест. Юнит тест только отлавивает ошибку. И не всегда из этого понятно в чем ошибка, и как ее отловить.
См. выше.
VD>Далее юнит-тесты все же сами по себе вызвают проблемы. а на самом деле ошибка находится в юнит-тесте и программист подтасовал результат кода под эту ошибку. Причем в рамках тество пробелем нет, но в реальном использовании они таки могут вылезти. Это уже наложенная ошибка. Так называемая — ошибка второго порядка.
Да, бывает и такое. Человек не машина..
VD>Ну и главное, юнет-тесты не отлавливают всех ошибко и не делают программу корректной. Они позволяют ввести дополнительный контроль. Это нужно четко понимать.
Равно как и любое тестирование. Никакое тестирование не отловит всех ошибок и не делают программу корректной. А хотелось бы Но Silver Bullet как обычно is out there.
VD>Есть разные задачи. Для одних юнит-тесты удобны. Для других неприменимы. Для теретих бессмысленны.
+1 VD> Тут нужны пакетные тесты содержащие много сложных сочетаний. Конечно и их можно назвать юнит-тестами, так как мы в итоге проверям результат пакетного теста с ожидаемым, но вот написать такой тест невозможно, да и не является он уже "Юнит". Он контролирует уже массу аспектов, а не какй-то один.
Лично я считаю (возможно ошибочно ) юнит тестом все, что может быполнить NUnit или его аналог
VD> что продукты лучше если их используют те кто пишет и если пользователи могут напрямую воздействовать на разработчиков.
dog food довольно распространненная практика. Но чем меньше багов получат конечные пользователи, тем лучше. По моему мнению юнит тесты позволяют снизить в какой-то мере количество багов в релизах. Не до нуля естественно..
VD>инструмент повышения качества кода. Не болше и не меньше.
Не совсем согласен. В примере который я приводил Lazy Cjow Rhrr ЮТ помогли сделать разработку быстрее. Но я повторюсь, возможно в других условиях результаты были бы другими.. Все та же пуля.. VD>Не надо низводить его до полной никчемности, но и не стоит делать из него религию и строить свою разработку исключительно отталкиваясь от них.
+1
minorlogic wrote: > Вот на эту мысль я и пытался навести , что тестировать наиболее удобно > маленькие отдельные модуле , а если сам тест встроен еще и в исполняемый > код , то это почти идеально. И разделять юнит тесты в некое отдельно > приложение не всегда разумно.
Ыыы... Ну вообще-то юнит-тесты — это как раз и есть наборы небольших
тестов, часто встраиваемых в сам код модуля (в Питоне, например).
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote: >> C>Пишем тест, который вызывает попадания во все ветки условий (их там >> C>совсем немного). >> Не понял, что проверяется и что от этого будет? Ведь я могу случайно (у >> меня такое действительно было) вместо < поставить >, и ЮТ уже ничем не >> поможет тогда. C>Для этого надо сравнивать результирующие данные с эталоном.
Ну, вот и получается, что я использую для этого комплексные тесты для всей системы, которые проверяют работу всей системы, а не её отдельных частей и что ЮТ тут не нужны совершенно.
>> У меня в алгоритме никаких веток, собственно нет. Там можно проверить >> только что вообще по всем узлам прошёл. Да и то будут ложные >> срабатывания, если граф несвязный. Для меня ложные срабатывания в ЮТ >> самая большая проблема была, когда я ими пытался пользоваться. C>Проблема с алгоритмической корректностью — это уже совсем другая история.
Алгорит у меня правильный, но я случайно поставил "<" вместо ">", мне нужно найти эту ошибку — она чисто кодировочная. Для некоторых алгоритмов это существенно, потому что не сразу заметно, хотя для крат. пути, конечно, сразу видно. Или, скажем, я забыл вызвать определённую функцию, которая иногда переставляет что-то местами, а иногда нет. Если я буду проверять код вручную на соответствие алгоритму — я её скорее всего довольно быстро найду, а если ЮТ, совершенно необязательно, если она появляется выборочно только для некоторых наборов. Поэт. лучше потратить время на ревизию, чем на написание ЮТ. А проверять всё комплексным тестом, возможно, автоматизированным.
C>Юнит-тесты нужны для проверки непосредственно правильности кода.
Ну и как я проверю правильность кода без проверки корректности алгоритма, реализующего метод Гаусса, например (простейший алгоритм, явно корректный). Меня там вообще на ЮТ достали ложные срабатывания, потому что я сделал автогенерацию неправильно. Я самого Гаусса написал быстрее раз в 5, чем правильные ЮТ для него. И, кстати, когда пришла пора использования, в моей реализации нашлась ошибка, которую ЮТ проглядели.
Здравствуйте, Mirrorer, Вы писали:
VD>> Тут нужны пакетные тесты содержащие много сложных сочетаний. Конечно и их можно назвать юнит-тестами, так как мы в итоге проверям результат пакетного теста с ожидаемым, но вот написать такой тест невозможно, да и не является он уже "Юнит". Он контролирует уже массу аспектов, а не какй-то один. M>Лично я считаю (возможно ошибочно ) юнит тестом все, что может быполнить NUnit или его аналог
ЮТ (в моём понимании), это то, что тестирует только некоторый конкретный небольшой модуль. Подразумевается при этом, что всё, что он использует, тестируется другими ЮТ или надёжно работает. ЮТ генерирует входные данные автоматически или по заданному набору, аналогично сверяет результат, по косвенным критериям правильности или по заданному набору правильных результатов.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Положа руку на сердце хотелось бы делать что-нибудь хотя бы приблизительно напоминающее (по надёжности) AXD 301 Но ресурсы малы и возможности не те...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Желаю всем быстрых как молния и надёжных как бронепоезд программ, за которые заказчики с раздостью бы платили много $$$$$$! LCR>
Надеюсь, за это время никому не понадобиться программ быстрее молнии и надёжней бронепоезда , что, впрочем, маловероятно
FDSC wrote: > C>Для этого надо сравнивать результирующие данные с эталоном. > Ну, вот и получается, что я использую для этого комплексные тесты для > всей системы, которые проверяют работу всей системы, а не её отдельных > частей и что ЮТ тут не нужны совершенно.
Нет, тестируешь эталонный выход именно для алгоритма (ручками на простом
графе из нескольких узлов).
> C>Проблема с алгоритмической корректностью — это уже совсем другая история. > Алгорит у меня правильный, но я *случайно* поставил "<" вместо ">", мне > нужно найти эту ошибку — она чисто кодировочная.
Пишем тесты, которые покрывают все ветки алгоритма. Обычно ошибка в
ветке алгоритма приведет к неправильному результату.
Здравствуйте, borisman3, Вы писали:
B>Достоинства,
который для меня — недостатки B>1) Заставляют продумывать заранее, что нужно запрограммировать (test-first).
Но совершенно не в том ракурсе, который нужен: всё получается как-то угловато
B>2) Заставляют строить модульные системы.
Модульные системы заставляет строить сложность.
А ЮТ заставляют их разбивать на мелкие модули, которые часто даже выглядят не очень, потому что систему разбивали быстро и никто не позаботился об архитектуре мелких модулей.
B>3) Действительно улучшают качество выходного продукта.
Да, но как уже тут говорилось, есть много других способов улучшить качество продукта за теже ресурсы, и никто не докажет, что ЮТ тут лучше других. Хотя, согласен, улучшают
B>4) Создают приятное (ложное) ощущение, что проект работает верно.
Лично мне они создают нервотрёпку...
B>Недостатки B>1) Вводят в ступор (тут без теста бы сообразить, с какого вообще конца браться, а ты гришь test-first...) B>2) Требуют дополнительных усилий на их написание B>3) Стремятся сделать проект менее гибким, а именно: B> 3.1) Требуют времени на пожжержание дополнительного кода B> 3.2) Требуют времени на согласование изменений в коде и тестах
Согласен
B>4) Создают ложное (приятное) ощущение, что проект работает верно.
Точнее, создают ложное ощущение, что проект можно больше не тестировать
B>В моей практике очень часто возникают такие ситуации, когда изменения в коде влекут такие катастрофические изменения тестов, что я просто начисто вырезаю с мясом целые тест-сюиты, так как не вижу смысла их поддерживать в дальнейшем.
Потому что незаботились об архитектуре ЮТ [! тут об нормальной-то архитектуре позаботились бы...]
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote: >> C>Для этого надо сравнивать результирующие данные с эталоном. >> Ну, вот и получается, что я использую для этого комплексные тесты для >> всей системы, которые проверяют работу всей системы, а не её отдельных >> частей и что ЮТ тут не нужны совершенно. C>Нет, тестируешь эталонный выход именно для алгоритма (ручками на простом C>графе из нескольких узлов).
Ручками всё правильно получится. Я же уже сказал: при кодировании случайно допустил ошибку. Даже выделил ведь жирно, а вы убрали из цитирования.
>> C>Проблема с алгоритмической корректностью — это уже совсем другая история. >> Алгорит у меня правильный, но я *случайно* поставил "<" вместо ">", мне >> нужно найти эту ошибку — она чисто кодировочная. C>Пишем тесты, которые покрывают все ветки алгоритма. Обычно ошибка в C>ветке алгоритма приведет к неправильному результату.
Часто очень сложно понять, как сделать входные данные, что бы побывать во всех ветках и это требует напряжённой и сложной работы. Поэтому я и говорю: лучше комплекно программу проверить, а вместо ЮТ лишний раз пробежаться по коду глазами.
C>Контроль покрытия осуществляется специальными инструментами. Могу C>порекламировать мой Boost.Coverage Вот пример вывода: C>http://elewise.com/~cyberax/cov_test/tz_database_.._.._.._boost_lexical_cast.hpp_fl.html
Спасибо. Однако кроме контроля покрытия ещё нужны входные данные, которые это покрытие обеспечат. Честно скажу: в моих приложениях я сам часто разрабатываю или модифицирую стандартные алгоритмы, но вот придумать такие входные данные практически никогда не могу. Вот если бы ваш инструмент мог их выдумывать — цены бы ему не было.
LCR>>Положа руку на сердце хотелось бы делать что-нибудь хотя бы приблизительно напоминающее (по надёжности) AXD 301 Но ресурсы малы и возможности не те...
FDS>Что такое AXD 301? FDS>
Тут Lazy Cjow Rhrr сказал, что в отпуск уходит, так что я отвечу.
The AXD 301 is a new, general-purpose, high-performance ATM switch from
Ericsson that can be used in several positions in a network. In its initial
release, the AXD 301 is scaleable from 10 Gbit/s—in one subrack—up to
160 Gbit/s. The AXD 301 supports every service category defined for ATM,
including ABR. An advanced buffering mechanism allows services to be
mixed without compromising quality.
Designed for non-stop operation, the AXD 301 incorporates duplicate hardware
and software modularity, which enables individual modules to be
upgraded without disturbing traffic. The switching system, which supports
both ATM Forum and ITU-T signaling, is easily managed using an embedded
Web-based management system.
Основной функционал написан на Эрланге, с дополнительной функциональностью на С и Java.
... << RSDN@Home 1.2.0 alpha rev. 647>> ... <<Kenji Kawai — 10 Kugutsuuta kagirohi ha yomi ni mata muto>> ...
Здравствуйте, FDSC, Вы писали:
LCR>>Положа руку на сердце хотелось бы делать что-нибудь хотя бы приблизительно напоминающее (по надёжности) AXD 301 Но ресурсы малы и возможности не те...
FDS>Что такое AXD 301? FDS>
Здравствуйте, vvaizh, Вы писали:
LCR>>Да, спасибо, но! Вся разница со способом сравнения с эталонным выводом в том, что здесь тестовый вывод выдирается из БД и над ним производятся некие вычисления?
V>зачем производить вычисления? V>вот у тебя отработала некая часть системы.. V>что после неё должно измениться? V>как ты это проверяешь при ручной отладке? V>наверно запрос какой нибудь тестовый выполняешь? V>вот и тут также абсолютно.. V>ты почитай пример там всё просто описано.. V>если процесс регистрации пользователя, то должна добавиться запись в таблице пользователей V>её запросом и смотришь..
Я, например, когда система работает неправильно, частенько сажусь и смотрю код, а не начинаю сразу искать ошибку в отладчике. Особенно, если эта ошибка локализована.
LCR>>Как это облегчит рутинность создания юнит-тестов?
LCR>>Нам теперь нужно сформировать (1) эталонный вывод,
V>нам не нужно его "формировать" V>нам нужно : V>1. запустить один раз тест, V>2. проконтроллировать глазками что тест на выход выдал правильный результат V>3. банально объявить этот результат эталонным V>всё это выполняется буквально несколькими нажатиями клавиши/мышки
То есть для этого нам нужна уже готовая правильно работающая программа. Такие ЮТ могут найти ошибку только при изменении программы, но не при её первичной отладке. Надеюсь, это очевидно.
LCR>>И этот комплекс мер избавляет от рутины при написании ЮТ? V>не избавляет, но существенно уменьшает рутину V>сводя её почти до тех же трудозатрат, которые и так необходимы при обычной отладке..
Совершенно не сводит к трудозатратам обычной отладки, совершенно!
V>просто обычно при недостатке времени тестируются считанные еденицы вариантов использования системы "в целом", V>не заморачиваясь на отдельных частях..
Ну, считанные единицы, это ты загнул: уж все варианты тестируются, и некоторые не по одному разу. И, заметь, если есть ошибка, то она вылетит сразу на одном тесте для всех модулей — т.е. объём тестов меньше. Другой вопрос, что в код часто то же вставляются проверки корректности, которые позволяют быстро локализовать ошибку.
Здравствуйте, FDSC, Вы писали:
LCR>>>Да, спасибо, но! Вся разница со способом сравнения с эталонным выводом в том, что здесь тестовый вывод выдирается из БД и над ним производятся некие вычисления?
V>>зачем производить вычисления? V>>вот у тебя отработала некая часть системы.. V>>что после неё должно измениться? V>>как ты это проверяешь при ручной отладке? V>>наверно запрос какой нибудь тестовый выполняешь? V>>вот и тут также абсолютно.. V>>ты почитай пример там всё просто описано.. V>>если процесс регистрации пользователя, то должна добавиться запись в таблице пользователей V>>её запросом и смотришь.. FDS>Я, например, когда система работает неправильно, частенько сажусь и смотрю код, а не начинаю сразу искать ошибку в отладчике. Особенно, если эта ошибка локализована.
а если не локализована?
тесты и призваны помочь быстро локализовать ошибки
LCR>>>Как это облегчит рутинность создания юнит-тестов? LCR>>>Нам теперь нужно сформировать (1) эталонный вывод, V>>нам не нужно его "формировать" V>>нам нужно : V>>1. запустить один раз тест, V>>2. проконтроллировать глазками что тест на выход выдал правильный результат V>>3. банально объявить этот результат эталонным V>>всё это выполняется буквально несколькими нажатиями клавиши/мышки FDS>То есть для этого нам нужна уже готовая правильно работающая программа. Такие ЮТ могут найти ошибку только при изменении программы, но не при её первичной отладке. Надеюсь, это очевидно.
ну всё же просто..
начинают же пробно запускать с первой строчки "hello world".. это уже правильная программа..
и вывод с неё же проверять..
а потом добавляют что то..
при этом вывод который нужно проверять всё разрастается..
тут то средство и помогает, так как показывает только как по сравнению с предыдущим эталоном вывод изменился..
не нужно тщательно глазами искать/вычитывать..
как говорится
1. палка
— проверил, записал результат как эталонный
2. палка
— проверил, переписал эталон
3. огуречик
— проверил, переписал эталон
4. вот и вышел человечек
— получили готовый тест и результат для заказчика
т.е. и писать помогает и тесты регрессионные сразу готовы
LCR>>>И этот комплекс мер избавляет от рутины при написании ЮТ? V>>не избавляет, но существенно уменьшает рутину V>>сводя её почти до тех же трудозатрат, которые и так необходимы при обычной отладке..
FDS>Совершенно не сводит к трудозатратам обычной отладки, совершенно!
ну.. к этому нужно стремиться..
т.е. простая мысль, человек при отладке выполняет над программой какие то действия,
запускает её с какими то данными
что то в ней делает..
средство должно максимально просто использовать эту информацию..
например пишет человек что то в program argument сразу в отладчике..
а почему там только одна строка?
а почему не несколько чтобы можно было выбирать, или сразу даже подрят в разных вариантах запускать?
и т.п.
Здравствуйте, FDSC, Вы писали:
LCR>>Положа руку на сердце хотелось бы делать что-нибудь хотя бы приблизительно напоминающее (по надёжности) AXD 301 Но ресурсы малы и возможности не те...
FDS>Что такое AXD 301? FDS>
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Твоя мысль согласуется с теми же Фаулерами, Беками и прочими: они говорят, чтобы мы вообще обложились тестами по самую макушку: юнит-, интеграционные, регрессионные, стресс-тесты, причём задействована должна быть каждая строчка в программе. Тогда можно с некоторой уверенностью сказать, что программа работает... Но всё это очень трудоёмко
"Атлас" тоже думал что трудоемко. Страна чуть без алкоголя не осталась.
Здравствуйте, borisman3, Вы писали:
B>Да и вообще. Вы сами уже ответили на все вопросы, когда сказали что worse is better. Мы будем делать то, что надо [клиенту], а того, что не надо [клиенту] мы делать не будем. А ему часто по барабану все эти тесты, красивая архитектура, запредельное качество. Клиент у нас с Вами — не министерство обороны с встроенными системами на подлодках, клиент у нас простодушный Большой Босс Владеющий Банками Заводами Пароходами, делайте то что ЕМУ важно, а на то, что программа вываливается в корку, когда пытаешься на сааамый удаленный пункт меню нажать он (клиент) даже внимания не обратит. А если обратит, честно признаем, что она (программа) не идальна, у всех свои недостатки. Клиент поймет.
Это смотря кто клиент и кто твоя фирма. Если фирма работает с откатами, то наверно поймет. А ежели без откатов, то тут хочешь или не хочешь нужно держать качество программы константным. К тому же, внутри фирмы человек(группа) которая делает меньше ошибок и быстрее тестируется значительно более высоко ценится.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.
Как я уже и говорил, для меня главное баланс. В той ситуации которую я описывал ЮТ показали себя с положительной стороны. Вопролен возможно что в другой команде или на другом проекте результат был бы другим. There is no silver bullet, как известно. 
А хотелось бы 
Но ресурсы малы и возможности не те...
[! тут об нормальной-то архитектуре позаботились бы...]
Страна чуть без алкоголя не осталась.