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

D>проблема тестирования системы в том, что мясо приходится на взаимодействие объектов, а не на сами объекты, простые и корректно выполняющие свои контракты.

Каким образом было обнаружено, что "сами объекты, простые и корректно выполняющие свои контракты"? unit test?
"взаимодействие объектов" — это отдельный вид тестирования перпендикулярный unit testам — integration tests...
И даже подходы другие (например в java просто JUnit не очень помогает в integration, там уже более тяжелая артиллерия
типа http://jakarta.apache.org/cactus или вообще тестирование на выделенном сервере автоматическими клиентами
или даже спец группой тестировщиков...

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

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

D>>проблема тестирования системы в том, что мясо приходится на взаимодействие объектов, а не на сами объекты, простые и корректно выполняющие свои контракты.

A>Каким образом было обнаружено, что "сами объекты, простые и корректно выполняющие свои контракты"? unit test?
нет. объекты такие тупые, что были написаны правильно с нуля )). неправильности отловлены в процессе отладки.

A>"взаимодействие объектов" — это отдельный вид тестирования перпендикулярный unit testам — integration tests...
A>И даже подходы другие (например в java просто JUnit не очень помогает в integration, там уже более тяжелая артиллерия
о чем и речь.

A>типа http://jakarta.apache.org/cactus или вообще тестирование на выделенном сервере автоматическими клиентами
A>или даже спец группой тестировщиков...
неудачный пример. посмотрите, что тестирует джакарта — (Servlets, EJBs, Tag Libs, Filters, ...). никак не похоже на сложную интегрированную систему.

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


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

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

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

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

D>не надо путать тесты и юнит-тесты. последние — одна из практик xp, которая, на мой взгляд, имеет очень ограниченное применение. о чем я и сказал

юнит-тесты — это то, что советует XP, но возникло это задолго до самого XP.

юнит-тесты — это часть так называемой V модели, в которой,
user requirements соответствуют приемочному тестированию (acceptance test)
system requirements — системному тестированию
спецификации модулей – модульному/unit тестированию

XP просто переняло уже давно известные практики.

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

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

я готов признать пользу от юнит-тестов для regression testing, но не всегда эта польза окупается затратами на их разработку.

и наконец, я скептически отношусь к xp и юнит-тестам в частности.

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

B>юнит-тесты — это то, что советует XP, но возникло это задолго до самого XP.
ok. я имел в виду юнит-тесты в том виде, в котором они применяются в xp.

B>юнит-тесты — это часть так называемой V модели, в которой,
B>user requirements соответствуют приемочному тестированию (acceptance test)
B>system requirements — системному тестированию
B>спецификации модулей – модульному/unit тестированию
все это больше применимо к разработке прикладных программ. я же говорю о системах, эти программы поддерживающих — среды выполнения, операционные системы.

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

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

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

B>>Извини за иронию, но не верю, что у тебя смысла в юнит тестах нету.
B>>Если ты сможешь кратко описать, что ты делаешь, то может быть и поверю...

То, что ты пишешь, это не описание того, что ты делаешь,
а описание границ применимости этого вида тестирования.

D>юнит-тесты и обвязка для них пишутся самим программистом. то есть качество тестов <= качество кода.
Качество тестов зависит от качества спецификаций модулей.
Его (качество) тоже можно контролировать.

D>юнит-тесты проверяют работу отдельных частей системы, а не их взаимодействие.

Конечно unit test не является integration test. Кто-то утверждает обратное?
unit test так же не заменит системного и многих других видов тестирования.

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

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

B>>юнит-тесты — это часть так называемой V модели, в которой,
B>>user requirements соответствуют приемочному тестированию (acceptance test)
B>>system requirements — системному тестированию
B>>спецификации модулей – модульному/unit тестированию
D>все это больше применимо к разработке прикладных программ. я же говорю о системах, эти программы поддерживающих — среды выполнения, операционные системы.

Прекращай героизацию системного программирования
Там есть свои особенности, но в целом там применимы все известные
подходы разработки программных продуктов.

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

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

D>>юнит-тесты и обвязка для них пишутся самим программистом. то есть качество тестов <= качество кода.
B>Качество тестов зависит от качества спецификаций модулей.
B>Его (качество) тоже можно контролировать.

D>>юнит-тесты проверяют работу отдельных частей системы, а не их взаимодействие.

B>Конечно unit test не является integration test. Кто-то утверждает обратное?
B>unit test так же не заменит системного и многих других видов тестирования.
будем считать, что договорились?

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

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

B>Прекращай героизацию системного программирования

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

B>>Внедрение юнит-тестов — это не более чем,
B>>внесение порядка и предсказуемости в такую деятельность.
D>и что, организован процесс автоматического тестирования?

Ну да. Это уже дело техники, включить прогон тестов в Build.
Каждую ночь гоняются все тесты и к утру все кому надо получают письма с логами.

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

N>В идеале, тесты должны полностью воссоздавать все окружение, в котором работает система. Например, если используется база данных, то хорошие тесты должны уметь создать ее "с нуля", прогнав необходимые скрипты, заполнить данными и "погонять" в разных режимах

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

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

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

_M>>Связность кода растет и никак с этим бороться не получается.
DEA>Значить, кто-то когда-то и неизвестно зачем лазит куда ему не надо.

DEA>Лекарство — плотные code review на потенциальних виновниках. С последующей профилактической (или пенициарной?) беседой. А вообще, "cvs annotate" выдумал не идиот...

А если потенциальный виновник только один? Или скажем два? Мне самому с собой проводить "пенециарную" беседу?

DEA>Или же, ваш дизайн прогнивает. Пора рефакторить.
DEA>Если есть на это время — вы счастливчик.
DEA>Если нет — мне вас жалко.

Эх, вот почему у меня все программы на C# сразу гнилые получаются? Даже те, которые в 500 строчек? Вот ну не работают, хоть ты тресни. Просто не разработка, а сплошной рефакторинг. А ведь сначала, на "бумаге", всё нормально выглядит, даже лучше, чем обычно

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

FDS>Вообще, когда используешь C# и .NET постоянно используешь сразу несколько компонентов. Обязательно надо что-то куда-то создать, записать, передать интерфейс и т.п. Куча служебных действий, иногда создаётся впечатление, что вернулся в assembler. Всё время думаешь о коде, а не о программе.

Вместо того, чтобы смеяться, лучше бы подсказали, что я не так делаю... а то я уже скоро на Nemerle и Scheme начну писать лучше, чем на C# .

P.S. Эх, пойду Владу ставить смайлик в отместку

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

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

B>>>Внедрение юнит-тестов — это не более чем,
B>>>внесение порядка и предсказуемости в такую деятельность.
D>>и что, организован процесс автоматического тестирования?

B>Ну да. Это уже дело техники, включить прогон тестов в Build.
B>Каждую ночь гоняются все тесты и к утру все кому надо получают письма с логами.
причем логи должны писаться и самими модулями, а не только тестами.
т.е. проект должен иметь достаточно мощную и удобную подсистему логирования.

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

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

А что понимается под "удобной" системой логирования?
Я имею ввиду, какие функции должны быть у этой системы, что бы она была удобной?

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

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

В целом да. Тяжко покрыть юнит-тестами драйвер на сях/ассемблере.

Но вот в то, что вы не делаете ошибок — извините не верю. Просто вы их потом долго и нудно ловите в софтайсе, выписывая на бумажке состояния регистров и адреса переходов. А вообще, я недавно обнаружил, что даже для низкоуровневых программ, C++ в связке с CPPUnit дают довольно малое падение в быстродействии и гораздо лучшую поддерживаемость. В том числе — и за счёт покрытия тестами.

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

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

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

B>>>>Внедрение юнит-тестов — это не более чем,
B>>>>внесение порядка и предсказуемости в такую деятельность.
D>>>и что, организован процесс автоматического тестирования?

B>>Ну да. Это уже дело техники, включить прогон тестов в Build.
B>>Каждую ночь гоняются все тесты и к утру все кому надо получают письма с логами.
sc>причем логи должны писаться и самими модулями, а не только тестами.
sc>т.е. проект должен иметь достаточно мощную и удобную подсистему логирования.

Ну да...
Одно другому не мешает.
Лог от юнит-теста мне сообщает только прошел ли тест или нет,
а другой лог (от самого модуля) дает информацию для анализа почему тест не прошел.
Если все из второго лога сразу понятно, то замечательно.
Иначе в дебагер...

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

N>Написание исчерпывающих unit-test'ов (ни одно исправление или улучшение кода не должно происходить без добавления соответствующего теста). Их регулярный автоматический запуск и автоматический контроль покрытости кода.

Это не всегда возможно. Точнее, это возможно для ограниченного круга задач.

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

IT>Это не всегда возможно. Точнее, это возможно для ограниченного круга задач.

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