Сам ответ и обсуждение тут - http://programmingmindstream.blogspot.ru/2014/06/dunit.html?showComment=1404246043248#c7116196987994053395
Цитата:
-----------------------------------
"Почему именно так "сделано"?"
-- потому что "мы так видим" :-) на основании НАШЕГО опыта, о чём и пытаемся рассказать.
"А можно, и в каких случаях, иначе?"
-- можно и ИНАЧЕ. На основании ДРУГОГО опыта.
"незнакомый инструмент"
-- мне вот казалось, что "на просторах интернета" про DUnit - масса всего написана.
Посему я пытался строить "план статей", не просто про DUnit, а про "приёмы работы с ним". Которые его авторы в него может быть и не закладывали.
А просто "как использовать DUnit" - мне эта тема казалась "тривиальной". Хотя и там конечно же есть что обсудить.
Хотя бы "зачем" GUITestRunner и ConsoleTestRunner.
Их названия на самом деле являются "ложными друзьями переводчика".
Там же дело не в GUI vs. Console, а в том "автоматически" тесты запускаются или "руками".
"Я с удовольствием прочитал уже новые вышедшие статьи."
-- это ОТРАДНО слышать. Может быть мы НЕ ЗРЯ старались :-) А мы - СТАРАЛИСЬ.
Вернёмся к:
"когда рассматриваешь для себя незнакомый инструмент"
-- "информации в интернетах" и от производителя правда не хватает? Надо писать на эту тему?
Или может быть "методология" тестирования недостаточно раскрыта? Кент Бек? Или Мартин Фаулер не всё сказали?
Или они "не донесли" МОТИВАЦИЮ тестирования?
Ну и подытожу:
Как я писал выше - было бы здорово - если бы быи КОНКРЕТНЫЕ вопросы, которых мы не коснулись. Ну и может быть (это было бы вообще здорово) примеры из жизни.
Мол - у меня "такая задачка" - как её тестировать. Или вот "у меня такое приложение" - как его тестировать.
Мы всё внимательно ЗАПИСЫВАЕМ и имеем в виду. И пытаемся корректировать наши планы в соответствии с задаваемыми вопросами.
Ну а про "DUnit Getting Started" - я уже писал выше. Это скорее всего - случится.
Да! И ещё. ХОЧУ ОТМЕТИТЬ, хотя мы иногда и упоминаем TDD как методологию и у нас даже был пост "применяем классическое TDD" (слово "классическое" - там не зря было в кавычках). Но! Мы НЕ ЗАНИМАЕМСЯ TDD и НЕ ПРОПАГАНДИРУЕМ TDD. Мы пытаемся излагать СВОЙ взгляд на тестирование программных систем, поиск ошибок и обеспечение СТАБИЛЬНОСТИ процесса разработки.
Именно в ключе "стабильности процесса разработки" мы и пытаемся рассматривать всё, что мы делаем.
Мы не являемся "адептами" или "фанатами" какой-то "теоретической" методологии, мы лишь пытаемся описать то, что мы почерпнули у классиков и то, что мы РЕАЛЬНО ПРИМЕНЯЕМ в жизни.
И у нас есть определённые Success-story, раскрыть которые сложно не потому, что это какие-то "технологические секреты", а потому, что для их понимания надо сильно детализировать предметную область.
Заканчиваю.
В общем сухой остаток - статьи ещё будут. И про DUnit - ОТДЕЛЬНО. Но!
Если вы будете задавать КОНКРЕТНЫЕ ВОПРОСЫ и приводить "примеры из жизни" - нам будет ГОРАЗДО ЛЕГЧЕ помочь вам в вашем "недопонимании". Или может быть вы "всё делаете верно", но сомневаетесь. Может быть мы тогда сможем помочь вам развеять сомнения.
---------------
Конец цитаты.
Цитата:
-----------------------------------
"Почему именно так "сделано"?"
-- потому что "мы так видим" :-) на основании НАШЕГО опыта, о чём и пытаемся рассказать.
"А можно, и в каких случаях, иначе?"
-- можно и ИНАЧЕ. На основании ДРУГОГО опыта.
"незнакомый инструмент"
-- мне вот казалось, что "на просторах интернета" про DUnit - масса всего написана.
Посему я пытался строить "план статей", не просто про DUnit, а про "приёмы работы с ним". Которые его авторы в него может быть и не закладывали.
А просто "как использовать DUnit" - мне эта тема казалась "тривиальной". Хотя и там конечно же есть что обсудить.
Хотя бы "зачем" GUITestRunner и ConsoleTestRunner.
Их названия на самом деле являются "ложными друзьями переводчика".
Там же дело не в GUI vs. Console, а в том "автоматически" тесты запускаются или "руками".
"Я с удовольствием прочитал уже новые вышедшие статьи."
-- это ОТРАДНО слышать. Может быть мы НЕ ЗРЯ старались :-) А мы - СТАРАЛИСЬ.
Вернёмся к:
"когда рассматриваешь для себя незнакомый инструмент"
-- "информации в интернетах" и от производителя правда не хватает? Надо писать на эту тему?
Или может быть "методология" тестирования недостаточно раскрыта? Кент Бек? Или Мартин Фаулер не всё сказали?
Или они "не донесли" МОТИВАЦИЮ тестирования?
Ну и подытожу:
Как я писал выше - было бы здорово - если бы быи КОНКРЕТНЫЕ вопросы, которых мы не коснулись. Ну и может быть (это было бы вообще здорово) примеры из жизни.
Мол - у меня "такая задачка" - как её тестировать. Или вот "у меня такое приложение" - как его тестировать.
Мы всё внимательно ЗАПИСЫВАЕМ и имеем в виду. И пытаемся корректировать наши планы в соответствии с задаваемыми вопросами.
Ну а про "DUnit Getting Started" - я уже писал выше. Это скорее всего - случится.
Да! И ещё. ХОЧУ ОТМЕТИТЬ, хотя мы иногда и упоминаем TDD как методологию и у нас даже был пост "применяем классическое TDD" (слово "классическое" - там не зря было в кавычках). Но! Мы НЕ ЗАНИМАЕМСЯ TDD и НЕ ПРОПАГАНДИРУЕМ TDD. Мы пытаемся излагать СВОЙ взгляд на тестирование программных систем, поиск ошибок и обеспечение СТАБИЛЬНОСТИ процесса разработки.
Именно в ключе "стабильности процесса разработки" мы и пытаемся рассматривать всё, что мы делаем.
Мы не являемся "адептами" или "фанатами" какой-то "теоретической" методологии, мы лишь пытаемся описать то, что мы почерпнули у классиков и то, что мы РЕАЛЬНО ПРИМЕНЯЕМ в жизни.
И у нас есть определённые Success-story, раскрыть которые сложно не потому, что это какие-то "технологические секреты", а потому, что для их понимания надо сильно детализировать предметную область.
Заканчиваю.
В общем сухой остаток - статьи ещё будут. И про DUnit - ОТДЕЛЬНО. Но!
Если вы будете задавать КОНКРЕТНЫЕ ВОПРОСЫ и приводить "примеры из жизни" - нам будет ГОРАЗДО ЛЕГЧЕ помочь вам в вашем "недопонимании". Или может быть вы "всё делаете верно", но сомневаетесь. Может быть мы тогда сможем помочь вам развеять сомнения.
---------------
Конец цитаты.
Комментариев нет:
Отправить комментарий