Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, sc, Вы писали:
sc>>причем логи должны писаться и самими модулями, а не только тестами. sc>>т.е. проект должен иметь достаточно мощную и удобную подсистему логирования.
FDS>А что понимается под "удобной" системой логирования? FDS>Я имею ввиду, какие функции должны быть у этой системы, что бы она была удобной?
Да, удобная, понятие растяжимое
Ну хотя бы чтобы логи были достаточно детальными (хотя это и от программиста сильно зависит), анализ логов должен быть удобным (возможно отдельная тулза), уровень логирования должен настраиваться при запуске, чтобы логи не много ресурсов отъедали, ну и чтобы легко и компактно можно было вставлять логирование в код.
Кроме того, что программист пишет в лог руками, необходимо добавить автомат. логи типа вход/выход в/из ф-ции, стек вызовов и др. полезную инфу
Re[3]: Ребят, я понимаю, что вам смешно, но проблема правда
Здравствуйте, FDSC, Вы писали:
FDS>Вместо того, чтобы смеяться, лучше бы подсказали, что я не так делаю... а то я уже скоро на Nemerle и Scheme начну писать лучше, чем на C# .
Чтобы сказать что ты делаешь не так надо с тобой поработать бок о бок.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Ребят, я понимаю, что вам смешно, но проблема правда
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
FDS>>Вместо того, чтобы смеяться, лучше бы подсказали, что я не так делаю... а то я уже скоро на Nemerle и Scheme начну писать лучше, чем на C# .
VD>Чтобы сказать что ты делаешь не так надо с тобой поработать бок о бок.
Спасибо за разъяснение.
Я просто нетерпелив и , как всегда, в плохом настроении, поэтому и пишу, что C# слишком сложен, Nemerle слишком сложен. А на самом деле, спроси меня про любимый Delphi, я и там найду, что покритиковать Так что не обращайте на меня особо внимания.
Здравствуйте, FDSC, Вы писали:
FDS>Вообще, когда используешь C# и .NET постоянно используешь сразу несколько компонентов. Обязательно надо что-то куда-то создать, записать, передать интерфейс и т.п. Куча служебных действий, иногда создаётся впечатление, что вернулся в assembler. Всё время думаешь о коде, а не о программе.
А ты не мог бы привести примеры этих "служебных действий", которые были тебе не нужны на С++?
По моим впечатлениям, код на С# обычно компактнее кода на С++.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, bkat, Вы писали:
B>Но мой опыт таков, что внедрение юнит-тестов всегда оправдывало себя. B>Затраты, на самом деле, не велики, а польза есть.
О, напиши юнит-тесты к Янусу, а потом мы посмотрим, какой процент известных ошибок ты ими поймаешь. Что то мне подсказывает, что очень маленький.
Здравствуйте, AndrewVK, Вы писали:
AVK>О, напиши юнит-тесты к Янусу,
Если изначально программа не проектировалась из расчета, что там будут unit-тесты, то именно юнит тесты написать уже не получится.
AVK>а потом мы посмотрим, какой процент известных ошибок ты ими поймаешь. Что то мне подсказывает, что очень маленький.
Кстати, какой процент известных ошибок помогла поймать статическая типизация?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>О, напиши юнит-тесты к Янусу,
ANS>Если изначально программа не проектировалась из расчета, что там будут unit-тесты, то именно юнит тесты написать уже не получится.
Знакомая отмазка.
AVK>>а потом мы посмотрим, какой процент известных ошибок ты ими поймаешь. Что то мне подсказывает, что очень маленький.
ANS>Кстати, какой процент известных ошибок помогла поймать статическая типизация?
Неизвестно. Те, что поймали, их никто из тех, кто их поймал не регистрировал.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>О, напиши юнит-тесты к Янусу,
ANS>>Если изначально программа не проектировалась из расчета, что там будут unit-тесты, то именно юнит тесты написать уже не получится.
AVK>Знакомая отмазка.
Это реальность жизни. С большой долей вероятности юнит-тесты нельзя написать ввиду отсутсвия самих юнитов.
Если тебе интересно, то приведи мне пример модуля из юнита, а я скажу тебе как на него написать юнит-тест.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>Знакомая отмазка.
ANS>Это реальность жизни.
Реальности жизни это тонны написанного кода. Переписывание их тебе никто не оплатит.
ANS> С большой долей вероятности юнит-тесты нельзя написать ввиду отсутсвия самих юнитов.
А что такое юниты в твоем понимании? И как определить их наличие/отсутствие?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, bkat, Вы писали:
B>>Но мой опыт таков, что внедрение юнит-тестов всегда оправдывало себя. B>>Затраты, на самом деле, не велики, а польза есть.
AVK>О, напиши юнит-тесты к Янусу, а потом мы посмотрим, какой процент известных ошибок ты ими поймаешь. Что то мне подсказывает, что очень маленький.
К Янусу писать не буду.
За "спасибо" не работаю
Ну и потом может вы и в самом деле сделали что-то принципиально новое
в разработке продуктов, что в итоге "старые" методы тестирования у вас
либо принпиально не применимы, либо дают нулевой эффект.
Может вы вообще все формально, на основании формальных же спецификаций, верифицируете
Я этого знать не могу
Кстати, если уж говорить об ошибках,
то важно еще учитывать, о каких ошибках идет речь
и об эффективности поиска ошибок.
Одно дело потрать год на обнаружение ошибок.
А другое дело за месяц найти те же самые ошибки.
Уверен, что целенаправленный поиск багов, в том числе с помощью юнит-тестов,
делает процесс поиска багов более эффективным,
Здравствуйте, AndrewVK, Вы писали:
ANS>>Это реальность жизни. AVK>Реальности жизни это тонны написанного кода. Переписывание их тебе никто не оплатит.
А я и несобираюсь его переписывать. Но люди иногда и пишут новый код. А со старым кодом, кроме тестеров никто не поможет.
ANS>> С большой долей вероятности юнит-тесты нельзя написать ввиду отсутсвия самих юнитов.
AVK>А что такое юниты в твоем понимании? И как определить их наличие/отсутствие?
То для чего можно написать юнит-тест То есть кусок кода, который можно выполнить не инициализируя всего приложения. Где-то так.
Здравствуйте, bkat, Вы писали:
B>Ну и потом может вы и в самом деле сделали что-то принципиально новое B>в разработке продуктов, что в итоге "старые" методы тестирования у вас B>либо принпиально не применимы, либо дают нулевой эффект.
Да нет, дело не в принципиально новом у нас, а в том, что старые методы, они далеко не для всего подходят.
B>Уверен, что целенаправленный поиск багов, в том числе с помощью юнит-тестов, B>делает процесс поиска багов более эффективным,
Вопрос только в одном — покрет ли повышение эффективности поиска багов затраты на написание юнит-тестов и модификацию их при рефакторинге системы. Для меня ответ совсем не очевиден, и я бы сильно поостерегся советовать использовать юнит-тестирование без понимания специфики конкретного проекта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>>Знакомая отмазка.
Чтобы приложение было можно оттестировать unit тестами, нужно проектировать близко к IoC.
ANS>>Это реальность жизни. AVK>Реальности жизни это тонны написанного кода. Переписывание их тебе никто не оплатит.
Никто и не говорит о переписывании... но вот начинать новый проект (или модуль к старому)
лучше бы с мыслью о UT в голове...
ANS>> С большой долей вероятности юнит-тесты нельзя написать ввиду отсутсвия самих юнитов. AVK>А что такое юниты в твоем понимании? И как определить их наличие/отсутствие?
Это примерно то, на что распадается приложение, которое проектируется с использованием паттерна IoC. Если приложение не проектировалось изначально под IoC, прикрутить потом IoC — себе дороже.
Re[10]: Ошибок не делает тот, кто ничего не делает
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос только в одном — покрет ли повышение эффективности поиска багов затраты на написание юнит-тестов и модификацию их при рефакторинге системы. Для меня ответ совсем не очевиден, и я бы сильно поостерегся советовать использовать юнит-тестирование без понимания специфики конкретного проекта.
Допустим стартует новый проект. Каким он должен быть чтобы юнит тесты были недостаточно эффективными ?
Я учавствовал в проекте, в котором юнит тесты начали писать на этапе активного багфиксинга. Процент выловленных багов благодаря юнит тестам был где-то 20%. Я вполне допускаю что для другого проекта этот показатель мог быть как 60% так и 0. А вот для нового проекта мне почему-то кажется что использование юнит тестов будет эффективным по умолчанию. Может я ошибаюсь
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[10]: Ошибок не делает тот, кто ничего не делает
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, bkat, Вы писали:
B>>Ну и потом может вы и в самом деле сделали что-то принципиально новое B>>в разработке продуктов, что в итоге "старые" методы тестирования у вас B>>либо принпиально не применимы, либо дают нулевой эффект.
AVK>Да нет, дело не в принципиально новом у нас, а в том, что старые методы, они далеко не для всего подходят.
Дак понятно, что серебрянных пуль нету.
B>>Уверен, что целенаправленный поиск багов, в том числе с помощью юнит-тестов, B>>делает процесс поиска багов более эффективным,
AVK>Вопрос только в одном — покрет ли повышение эффективности поиска багов затраты на написание юнит-тестов и модификацию их при рефакторинге системы. Для меня ответ совсем не очевиден, и я бы сильно поостерегся советовать использовать юнит-тестирование без понимания специфики конкретного проекта.
Да, для каждого проекта надо решать заново, что и как тестируется.
Это даже надо заранее планировать.
Юнит-тестирование — это один из "тулов" обеспечения качества.
О нем надо знать и при необходимости осознанно пользоваться.
Советовать этим пользоваться всегда и при любых условиях так не разумно,
на мой взгляд, как и "сильно остерегаться советовать использовать".
Членам РСДН стоит вообще быть осторожным с советами, потому что к ним прислушиваются
Re[13]: Ошибок не делает тот, кто ничего не делает
Здравствуйте, aka50, Вы писали:
AVK>>>>Знакомая отмазка. A>Чтобы приложение было можно оттестировать unit тестами, нужно проектировать близко к IoC.
Янус спроектирован таким образом. Только проблема там в другом месте.
AVK>>А что такое юниты в твоем понимании? И как определить их наличие/отсутствие? A>Это примерно то, на что распадается приложение, которое проектируется с использованием паттерна IoC. Если приложение не проектировалось изначально под IoC, прикрутить потом IoC — себе дороже.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос только в одном — покрет ли повышение эффективности поиска багов затраты на написание юнит-тестов и модификацию их при рефакторинге системы. Для меня ответ совсем не очевиден, и я бы сильно поостерегся советовать использовать юнит-тестирование без понимания специфики конкретного проекта.
Проведение рефакторинга системы без юнит-тестов — это bugs*bugs при котором bugs -> infinity
Re[14]: Ошибок не делает тот, кто ничего не делает
.
1.2.0 alpha rev. 655
