Кстати. Есть вопрос. Про DUnit.
Есть "мысли" написать "цикл" - "Что такое DUnit и как оно устроено изнутри".
1. Как запускаются тесты.
2. Что такое Startup/Teardown.
3. Какая связь с JUnit и CUnit.
4. Как связаны тесты и published-методы.
5. Как делать тесты без published-методов.
6. Как делать парметризованные тесты.
7. Что такое AwaitableException.
8. Как ловить утечки памяти.
9. Что такое ITest и ITestSuite.
10. Какие есть расширения и надстройки для DUnit.
11. Что такое GUITestRunner и ConsoleTestRunner. И есть ли альтернативы.
12. Что же делать с DUnit и FM.
13. Как делать анти-тесты.
etc.
Эта тема интересна?
Мне то лично про это "писать неинтересно", потому что - "код читаю".. Но "оказывается" - "есть вопросы"...
Есть "мысли" написать "цикл" - "Что такое DUnit и как оно устроено изнутри".
1. Как запускаются тесты.
2. Что такое Startup/Teardown.
3. Какая связь с JUnit и CUnit.
4. Как связаны тесты и published-методы.
5. Как делать тесты без published-методов.
6. Как делать парметризованные тесты.
7. Что такое AwaitableException.
8. Как ловить утечки памяти.
9. Что такое ITest и ITestSuite.
10. Какие есть расширения и надстройки для DUnit.
11. Что такое GUITestRunner и ConsoleTestRunner. И есть ли альтернативы.
12. Что же делать с DUnit и FM.
13. Как делать анти-тесты.
etc.
Эта тема интересна?
Мне то лично про это "писать неинтересно", потому что - "код читаю".. Но "оказывается" - "есть вопросы"...
Да, такой материал был бы востребован.
ОтветитьУдалитьПоскольку внятного, системного изложения способов применения DUnit, лично мне не встречалось.
Людям приходится смотреть примеры использования, а оттуда далеко не всегда сразу удаётся извлечь всё то, что может потребоваться. В результате страдает эффективность работы на начальном этапе, а сам начальный этап - затягивается.
С учётом того, что по меньшей мере - для многих, DUnit непривычный инструмент, необходимость которого не очевидна, цикл статей на эту тему помог бы внести ясность в этот вопрос.
Можно тогда ещё вопрос? Какие ИМЕННО неясности с DUnit существуют? Чтобы в ПЕРВУЮ ГОЛОВУ их осветить.
ОтветитьУдалитьДа. И чем примеры не хороши? Может быть стоит взять и описать примеры детально? Как Вы думаете?
Да! И что вы подразумевается под "начальным этапом"? Наши посты про "калькулятор" не пролили ясность на "начальный этап"?
«Можно тогда ещё вопрос? Какие ИМЕННО неясности с DUnit существуют? Чтобы в ПЕРВУЮ ГОЛОВУ их осветить.»
ОтветитьУдалить-- Зачем вообще нужен этот фреймворк?
Зачем использовать "какой-то DUnit" если тестовое приложение можно создать самому "вручную", без изучения соглашений DUnit вроде оформления атомартых тестов в виде published-методов и регистрации тестов посредством RegisterTest в секции инициализации модуля.
Чем лучше пакеты тестов DUnit атомарных приложений на общей базе кода?
«Да. И чем примеры не хороши? Может быть стоит взять и описать примеры детально? Как Вы думаете?»
-- Они всем хороши. Но каждый тест решает свою конкретную задачу.
Например, зачем нужны все эти CheckEquals, CheckNotNull и почему их не заменить простым Assert?
Какой смысл объединять тесты в классы, а если и объединять, то по какому критерию?
В каких случаях в тестовом приложении возникает потребность в нескольких классах-потомках TTestCase?
Пригодился бы обзор возможностей DUnit и функциональности, рекомендованной к использованию. Разумеется, с описанием ситуаций, когда эту функциональность следует применять.
«Да! И что вы подразумевается под "начальным этапом"? Наши посты про "калькулятор" не пролили ясность на "начальный этап"?»
-- Под начальным этапом понимается период времени, когда разработчик задаёт себе вопросы вроде тех, что я сформулировал выше.
В постах "про калькулятор" рассматривается IMHO весьма специфический способ применения DUnit, а именно, применение его для тестирования функциональности в условиях активного GUI-интерфейса.
Это во-первых, не всегда возможно просто обеспечить, во-вторых, даже если это нужно, не везде применим подход, основанный на прямом взаимоденйствии с элементами управления, а в третьих, часто (возможно - чаще) приходится тестировать не интерактивную функциональность.
Операции же с элементами управления "загораживают" применение функциональности DUnit. Но возможно, это только мне это показалось.
"Зачем вообще нужен этот фреймворк?
УдалитьЗачем использовать "какой-то DUnit" если тестовое приложение можно создать самому "вручную", без изучения соглашений DUnit вроде оформления атомартых тестов в виде published-методов и регистрации тестов посредством RegisterTest в секции инициализации модуля.
Чем лучше пакеты тестов DUnit атомарных приложений на общей базе кода?"
-- я себе ЗАДАВАЛ этот вопрос. И пытался делать "тесты на коленке". ПОВЕРЬТЕ - DUnit - УДОБНЕЕ.
"В постах "про калькулятор" рассматривается IMHO весьма специфический способ применения DUnit, а именно, применение его для тестирования функциональности в условиях активного GUI-интерфейса."
Удалить-- это НЕ ТАК.. От GUI мы ушли во ВТОРОМ же посте. Или в третьем.
"Это во-первых, не всегда возможно просто обеспечить, во-вторых, даже если это нужно, не везде применим подход, основанный на прямом взаимоденйствии с элементами управления, а в третьих, часто (возможно - чаще) приходится тестировать не интерактивную функциональность."
Удалить-- вы МЕНЯ НЕВНИМАТЕЛЬНО читали. Я НЕ РАЗ написал, что GUI-Тесты это "от бедности".
"Например, зачем нужны все эти CheckEquals, CheckNotNull и почему их не заменить простым Assert?"
Удалить-- они хороши ДИАГНОСТИКОЙ того - ГДЕ и КАКАЯ ошибка произошла.
"Пригодился бы обзор возможностей DUnit и функциональности, рекомендованной к использованию. Разумеется, с описанием ситуаций, когда эту функциональность следует применять."
Удалить-- Понял. Попробуем сделать.
"Какой смысл объединять тесты в классы, а если и объединять, то по какому критерию?"
Удалить-- тут "чистое ООП" - по мере надобности.
Можно все тесты СВАЛИТЬ в ОДИН класс, а можно КАЖДОМУ тесту сделать СВОЙ КЛАСС. Тут ровно ТАК ЖЕ как и при разработке. Какими критериями вы руководствуетесь?
"Чем лучше пакеты тестов DUnit атомарных приложений на общей базе кода?"
Удалить-- тем что можно "галочки на тестах поставить", а не реализовывать это в КАЖДОМ КОНКРЕТНОМ приложении.
Спасибо Вам! Если ответите в будущей(-их) статье(-ях) на эти вопросы, то я с огромным нетерпением жду ее(-их). Хорошей информации, кроме скудной справки, я не смог найти. А тема нужная. И на первоначальном этапе освоения, крайне интересен опыт автора статьи, а не только собственный метод "проб и ошибок".
Удалить"крайне интересен опыт автора статьи"
Удалить-- ну про свой опыт мы как раз пытаемся рассказывать. И НЕ ЗРЯ упираем на ЭТАЛОНЫ. Они в некотором роде замена mock'ам.
"а не только собственный метод "проб и ошибок""
-- а он есть? Интересно было бы послушать. Чтобы сделать выводы - о чём нам ещё в первую очередь рассказать. И насколько это востребовано.
"Если ответите в будущей(-их) статье(-ях) на эти вопросы, то я с огромным нетерпением жду ее(-их)."
-- обязательно "ответим". Точнее напишем "то что планировали". У нас есть план статей и мы его придерживаемся.
Но вообще говоря - если бы были конкретные вопросы и/или "примеры из жизни", то мы могли бы и скорректировать свой план.
Хотя тема "DUnit Getting Started" - зреет в наших умах. Она похоже - востребована.
И кстати что касается published - это НЕ ЕДИНСТВЕННАЯ возможность... Про АЛЬТЕРНАТИВЫ я ещё напишу...
ОтветитьУдалитьАлександр, а зачем Вы меня убеждаете? Я ответы знаю :-) Они правда, отличаются от Ваших, но они есть.
ОтветитьУдалитьВот если Вы дадите в посте или серии постов развёрнутые ответы на обозначенные вопросы или на вопросы, которые Вы сами перед собой ставили - это будет интересно и полезно.
На тему "невнимательности"... Я бы попросил Вас воздержаться, если есть такая возможность, от оценочных суждений в отношении моей персоны.
Вы сформулировали вопрос - я на него ответил. В личном сообщении к Вам я указал, что от оценок чужого труда (тем более - публичных) воздерживаюсь. Я не говорю, что Вы всё свели к тестированию GUI-интерфеса, но и не нахожу Ваши посты "про калькулятор" путеводителем по DUnit.
«"Какой смысл объединять тесты в классы, а если и объединять, то по какому критерию?"
-- тут "чистое ООП" - по мере надобности.
Можно все тесты СВАЛИТЬ в ОДИН класс, а можно КАЖДОМУ тесту сделать СВОЙ КЛАСС. Тут ровно ТАК ЖЕ как и при разработке. Какими критериями вы руководствуетесь?»
-- Это ко мне вопрос?
"Это ко мне вопрос?"
Удалить-- ну да.
"Я не говорю, что Вы всё свели к тестированию GUI-интерфеса, но и не нахожу Ваши посты "про калькулятор" путеводителем по DUnit."
Удалить-- в каком месте мы свели к тестированию GUI? Мне "казалось", что мы пишем о том, как "от тестирования GUI уйти"...
Возможно - плохо пишем...
"но и не нахожу Ваши посты "про калькулятор" путеводителем по DUnit."
Удалить-- можно вопрос? Что именно про DUnit мы не рассказали?
«можно вопрос? Что именно про DUnit мы не рассказали?»
Удалить-- Александр... Есть Ваши посты, в которых Вы применяете DUnit. Это важно, нужно и полезно.
Но пост, в котором расположены эти комментарии (мне по крайней мере, так показалось) посвящён Вашему намерению написать цикл статей относительно DUnit.
Мне думалось (могу конечно ошибаться), что в в этих статьях будет дан обзор возможностей DUnit и рекомендации по применению этих возможностей, возможно, с отсылками к постам, посвящённым тестированию калькулятора.
Изложение, ориентированное на DUnit было бы полезно для людей, которые этот DUnit в глаза не видели, а о JUnit - ни разу не слышали.
Я только об этом.
Отвечая прямо на Ваш вопрос могу сказать следующее: я не смотрел исходные тексты Ваших тестов детально - просматривал только статьи. Возможно, так или иначе, Вы затронули большинство особенностей DUnit (хотя поручиться не могу) но для знакомства с этими возможностями необходимо изучение контекста решаемой задачи.
IMHO это нужно не всем. А вот познакомиться с возможностями DUnit было бы полезно безотносительно Вашего примера. Или обращаясь к нему по мере возникновения интереса к тем или иным возможностям DUnit.
"Александр, а зачем Вы меня убеждаете? Я ответы знаю :-)"
ОтветитьУдалить-- я - НЕ УБЕЖДАЮ. Есть ОТВЕТЫ - дайте их, чтобы мы не писали "в пустоту".
"На тему "невнимательности"... Я бы попросил Вас воздержаться, если есть такая возможность, от оценочных суждений в отношении моей персоны."
Удалить-- и ВСЁ ЖЕ - мы писали НЕ ПРО GUI-тесты. А Вы их почему-то "педалируете"... Это проблема нашего изложения?
Я ничего не педалирую. Просто обратил внимание на код вида:
Удалить<code>
aForm.edtFirstArg.Text := FloatToStr(aA);
... ... ...
aForm.btnAdd.Click;
</code>
вот здесь например...
Я не говорю, что во всех тестах Вы тестирует активную форму калькулятора. Но с одной стороны, такие тесты у Вас есть, с другой, в тех местах где это не так, достаточно других специфичных вещей (вроде базового класса для тестов) которые акцентируют внимание не на DUnit, а на выбранной Вами архитектуре тестов, которая сильно зависит от решаемой задачи.
«Александр, а зачем Вы меня убеждаете? Я ответы знаю :-)"
Удалить-- я - НЕ УБЕЖДАЮ. Есть ОТВЕТЫ - дайте их, чтобы мы не писали "в пустоту".»
-- Честно говоря, здесь я Вас немного не понял.
С одной стороны, Вы собрались писать о DUnit, с другой, как мне показалось, Вы ожидаете ответов на обозначенные вопросы от меня.
Я, в принципе, не против их обсудить, но просто не думаю, что комментарии - удобный формат.
Если Вам интересно моё мнение на этот счёт - пишите в личку.
Извините, что вклиниваюсь в уже струю ветвь дискуссии. Я с удовольствием прочитал уже новые вышедшие статьи. Понимаете, когда рассматриваешь для себя незнакомый инструмент, всегда остаются открытыми вопросы правильности и эффективности использования его. Как убедится, что все тобой правильно понято? Нажить опыт. А вот это путь тернистый. Читая примеры я для себя пока не могу ответить на два вопроса:
Удалить- Почему именно так "сделано"?
- А можно, и в каких случаях, иначе?
"Почему именно так "сделано"?"
Удалить-- потому что "мы так видим" :-) на основании НАШЕГО опыта, о чём и пытаемся рассказать.
"А можно, и в каких случаях, иначе?"
-- можно и ИНАЧЕ. На основании ДРУГОГО опыта.
"незнакомый инструмент"
-- мне вот казалось, что "на просторах интернета" про DUnit - масса всего написана.
Посему я пытался строить "план статей", не просто про DUnit, а про "приёмы работы с ним". Которые его авторы в него может быть и не закладывали.
А просто "как использовать DUnit" - мне эта тема казалась "тривиальной". Хотя и там конечно же есть что обсудить.
Хотя бы "зачем" GUITestRunner и ConsoleTestRunner.
Их названия на самом деле являются "ложными друзьями переводчика".
Там же дело не в GUI vs. Console, а в том "автоматически" тесты запускаются или "руками".
"Я с удовольствием прочитал уже новые вышедшие статьи."
-- это ОТРАДНО слышать. Может быть мы НЕ ЗРЯ старались :-) А мы - СТАРАЛИСЬ.
Вернёмся к:
"когда рассматриваешь для себя незнакомый инструмент"
-- "информации в интернетах" и от производителя правда не хватает? Надо писать на эту тему?
Или может быть "методология" тестирования недостаточно раскрыта? Кент Бек? Или Мартин Фаулер не всё сказали?
Или они "не донесли" МОТИВАЦИЮ тестирования?
Ну и подытожу:
Как я писал выше - было бы здорово - если бы быи КОНКРЕТНЫЕ вопросы, которых мы не коснулись. Ну и может быть (это было бы вообще здорово) примеры из жизни.
Мол - у меня "такая задачка" - как её тестировать. Или вот "у меня такое приложение" - как его тестировать.
Мы всё внимательно ЗАПИСЫВАЕМ и имеем в виду. И пытаемся корректировать наши планы в соответствии с задаваемыми вопросами.
Ну а про "DUnit Getting Started" - я уже писал выше. Это скорее всего - случится.
Да! И ещё. ХОЧУ ОТМЕТИТЬ, хотя мы иногда и упоминаем TDD как методологию и у нас даже был пост "применяем классическое TDD" (слово "классическое" - там не зря было в кавычках). Но! Мы НЕ ЗАНИМАЕМСЯ TDD и НЕ ПРОПАГАНДИРУЕМ TDD. Мы пытаемся излагать СВОЙ взгляд на тестирование программных систем, поиск ошибок и обеспечение СТАБИЛЬНОСТИ процесса разработки.
Именно в ключе "стабильности процесса разработки" мы и пытаемся рассматривать всё, что мы делаем.
Мы не являемся "адептами" или "фанатами" какой-то "теоретической" методологии, мы лишь пытаемся описать то, что мы почерпнули у классиков и то, что мы РЕАЛЬНО ПРИМЕНЯЕМ в жизни.
И у нас есть определённые Success-story, раскрыть которые сложно не потому, что это какие-то "технологические секреты", а потому, что для их понимания надо сильно детализировать предметную область.
Заканчиваю.
В общем сухой остаток - статьи ещё будут. И про DUnit - ОТДЕЛЬНО. Но!
Если вы будете задавать КОНКРЕТНЫЕ ВОПРОСЫ и приводить "примеры из жизни" - нам будет ГОРАЗДО ЛЕГЧЕ помочь вам в вашем "недопонимании". Или может быть вы "всё делаете верно", но сомневаетесь. Может быть мы тогда сможем помочь вам развеять сомнения.
Спасибо за Ваши замечания, пост о DUnit будет. Думаю будет в стиле "DUnit для чайников". Хотя тут ещё надо объем обсудить.
ОтветитьУдалить