Заранее прошу прощения если подобный вопрос уже поднимался — поиском не нашел.
Прочел очередную статейку по Test Driven Development и опять — взяло меня deja vu. Автор берет какой-нибудь простенький изолированный класс типа Money или мало кому нужный типа TriangleAnalyser и весело пишет для него юнит тесты. "Конечно", — думаешь, -"для такого класса написать тесты — пара пустяков."
Знаю, сейчас мне скажут: надо лучше проектировать, тогда и таких вопросов не возникнет. Но могу с уверенностью возразить, что все равно возникнут. Вот например, я сейчас разрабатываю простенький редактор для статей в CMS — на основе JTextPane. Практически весь мой код — это классы, расширяющие стандартные составные части этого компонента. Попробуй протестируй все возможные ситуации! На написание тестов уйдет на порядки больше времени, чем на написание самой программы.
Так вот.. может кто знает, где описано, как надо писать тесты для более сложных и реальных программных модулей — для пользовательского интерфейса, или, скажем, для классов-наследников библиотечных классов, или участвующих в отношениях, задаваемыми различными паттернами? Очень желательно с примерами.
Просто надоело — пишутся тесты только для "написанных с нуля" простеньких собственных классов — а про то, как действительно важные вещи протестировать — нигде не слова. Интересно, может ли быть сформулировано правило, по которому можно протестировать практически любой кусок программы?
Реакции типа "да ты нифига не понял в этой жизни" принимаются тоже, при наличии аргументации
Re: Test Driven Development - только для простеньких классов
A.J. -> "Test Driven Development — только для простеньких классов?" :
A> Просто надоело — пишутся тесты только для "написанных с нуля" A> простеньких собственных классов — а про то, как действительно важные A> вещи протестировать — нигде не слова. Интересно, может ли быть A> сформулировано правило, по которому можно протестировать практически A> любой кусок программы?
Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как
правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую
електроникой грань, все встанет на свои места
A> Реакции типа "да ты нифига не понял в этой жизни" принимаются тоже, A> при наличии аргументации
Здравствуйте, A.J., Вы писали:
AJ>Знаю, сейчас мне скажут: надо лучше проектировать, тогда и таких вопросов не возникнет. Но могу с уверенностью возразить, что все равно возникнут. Вот например, я сейчас разрабатываю простенький редактор для статей в CMS — на основе JTextPane. Практически весь мой код — это классы, расширяющие стандартные составные части этого компонента. Попробуй протестируй все возможные ситуации! На написание тестов уйдет на порядки больше времени, чем на написание самой программы. AJ>Так вот.. может кто знает, где описано, как надо писать тесты для более сложных и реальных программных модулей — для пользовательского интерфейса, или, скажем, для классов-наследников библиотечных классов, или участвующих в отношениях, задаваемыми различными паттернами? Очень желательно с примерами.
Имхо, такие тесты должны выполнять smoke тестирование — иначе действительно написание кода будет выливаться в написание тестов. Но как показывает опыт — потраченные пол-дня позволят выловить пару багов и сократить время последующего тестирования. Имхо, такой процесс не отменяет этапа тестирования, но позволит его сократить.
Re[2]: Test Driven Development - только для простеньких клас
Здравствуйте, hrg, Вы писали:
hrg>Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как hrg>правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую hrg>електроникой грань, все встанет на свои места
То есть получается — если уже начал писать программу без ТДД, то все, поезд
ушел?
В принципе вопрос не отменяется — можно ведь и с нуля писать прогу, которую будет очень трудно протестировать.
Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?
Re[2]: Test Driven Development - только для простеньких клас
Здравствуйте, Gramazeka, Вы писали:
G> Имхо, такие тесты должны выполнять smoke тестирование — иначе действительно написание кода будет выливаться в написание тестов. Но как показывает опыт — потраченные пол-дня позволят выловить пару багов и сократить время последующего тестирования. Имхо, такой процесс не отменяет этапа тестирования, но позволит его сократить.
А можно поподробнее про smoke тестирование? Просто нигде раньше не встречал такого термина.
Re: Test Driven Development - только для простеньких классов
Здравствуйте, A.J., Вы писали:
AJ>Знаю, сейчас мне скажут: надо лучше проектировать, тогда и таких вопросов не возникнет. Но могу с уверенностью возразить, что все равно возникнут. Вот например, я сейчас разрабатываю простенький редактор для статей в CMS — на основе JTextPane. Практически весь мой код — это классы, расширяющие стандартные составные части этого компонента. Попробуй протестируй все возможные ситуации! На написание тестов уйдет на порядки больше времени, чем на написание самой программы.
Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.
Re[3]: Test Driven Development - только для простеньких клас
Здравствуйте, A.J., Вы писали:
AJ>Здравствуйте, hrg, Вы писали:
hrg>>Как ты думаешь — почему это называетя "Разработка через тесты", а не "Как hrg>>правильно тестировать программы"? Когда уловишь эту тонкую, едва различимую hrg>>електроникой грань, все встанет на свои места
AJ>То есть получается — если уже начал писать программу без ТДД, то все, поезд AJ>ушел?
Не совсем.
Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения.
Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.
AJ>В принципе вопрос не отменяется — можно ведь и с нуля писать прогу, которую будет очень трудно протестировать.
А то ж.
AJ>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?
Как обычно. Делаешь объектную декомпозицию задачи, выделяешь классы-участники, для каждого из них пишешь изолированные тесты.
--
Владимир.
Re[2]: Test Driven Development - только для простеньких клас
Большая система или малая не особо и играет роль. Я бы писал тесты для тех мест, которые вызывают сомнения, другими словами уничтожал соменения покрытием тестов.
Re: Test Driven Development - только для простеньких классов
Здравствуйте, Павел Леонов, Вы писали:
ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.
А я всегда считал, что от перемены мест слагаемых сумма не меняется...
Объем кода теста, имхо, не очень зависит от того, когда я его буду писать — до или после написания тестируемого кода.
То, что предлагается — по сути размазать написание тестов по всему процессу создания программы — на мой скромный взгляд, является всего лишь неким психологическим самообманом
А тот ворох религиозно-политико-идеологических фраз, который заставляют заучивать всех новичков, например
ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?"
... это прямо как заклинания, вводящие новичка в транс, чтобы он поверил в то, что сумма от перемены мест слагаемых таки изменится
A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :
A> Здравствуйте, hrg, Вы писали:
hrg>> Как ты думаешь — почему это называетя "Разработка через тесты", а hrg>> не "Как правильно тестировать программы"? Когда уловишь эту hrg>> тонкую, едва различимую електроникой грань, все встанет на свои hrg>> места
A> То есть получается — если уже начал писать программу без ТДД, то A> все, поезд ушел?
Нупочимужи? Просто часть проги у тебя будет непокрытой тестами. Потом ее
привелешь к нужному виду.
Кстате — TDD очень хорошо завязан на реализацию use-case'ов.
A> В принципе вопрос не отменяется — можно ведь и с нуля писать прогу, A> которую будет очень трудно протестировать. A> Как, скажем, будет выглядеть тест (или набор тестов), проверяющий A> выполнение такого требования: любой XHTML-документ, соответствующий A> DTD, должен быть корректно преобразован в собственное программное A> представление (иерархию элементов)?
Я вроде в этой эхе расписывал, как это делается.
Вкратце — что такое иерархия элементов — это дерево. У тебя функции
построения дерева.
Берешь кусок документа и строишь для него дерево руками.
Потом запускаешь парсер и смотришь, что он тебе построил.
Если два дерева идентичны — то тест прошел.
Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку
за наши молитвы."
Posted via RSDN NNTP Server 1.9 beta
Re[3]: Test Driven Development - только для простеньких клас
XopoSHiy -> "Re[2]: Test Driven Development — только для простеньких клас" :
X> Здравствуйте, Павел Леонов, Вы писали:
ПЛ>> Я думаю при таком подходе поднимается вопрос "А что же на самом ПЛ>> деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну ПЛ>> типа пусть там все будет все круто". Поэтому очередной тест ПЛ>> наверное стоит рассматривать как этап достяжения цели, а не как ПЛ>> некий антивирус, мол "Что нибудь да поймает". Во втором случае ПЛ>> получиться "Пойди туда не заню куда...", крыша съедет составлять ПЛ>> их.
X> А я всегда считал, что от перемены мест слагаемых сумма не X> меняется... X> Объем кода теста, имхо, не очень зависит от того, когда я его буду X> писать — до или после написания тестируемого кода.
X> То, что предлагается — по сути размазать написание тестов по всему X> процессу создания программы — на мой скромный взгляд, является всего X> лишь неким психологическим самообманом
Ну как тебе сказать. В традиционном понимании мы начинаем писать прогу, в
уме представляя, что она должна делать. А тут ты сначала пишешь, что на
должна делать (можно прям сценарий из use-case'a выдирать), а потом пишешь
реализацию этого.
X> А тот ворох религиозно-политико-идеологических фраз, который X> заставляют заучивать всех новичков, например
Тут тоже есть свои причины. Можно долго и пространно объяснять, что, почему,
как, по какой причине, а можно просто сказать: "Будешь делать не так,
убунах".
ПЛ>> Я думаю при таком подходе поднимается вопрос "А что же на самом ПЛ>> деле я хочу сделать/достичь?"
X> ... это прямо как заклинания, вводящие новичка в транс, чтобы он X> поверил в то, что сумма от перемены мест слагаемых таки изменится
Здравствуйте, Павел Леонов, Вы писали:
ПЛ>Я думаю при таком подходе поднимается вопрос "А что же на самом деле я хочу сделать/достичь?", вместо абстрактно-человеческого "Ну типа пусть там все будет все круто". Поэтому очередной тест наверное стоит рассматривать как этап достяжения цели, а не как некий антивирус, мол "Что нибудь да поймает". Во втором случае получиться "Пойди туда не заню куда...", крыша съедет составлять их.
Так получается, тесты проверяют лишь минимальную функциональность. Типа, "по крайней мере в одном случае (чаще всего простейшем) оно работает!"
Ну тогда не надо называть это тестами. Менее бы вводило в заблуждение что-нибудь вроде "иллюстрации простейшего использования"
Re[4]: Test Driven Development - только для простеньких клас
Здравствуйте, _vovin, Вы писали:
AJ>>То есть получается — если уже начал писать программу без ТДД, то все, поезд AJ>>ушел?
_>Не совсем. _>Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения. _>Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.
Так вопрос в том — чем этот "новый" вид отличается от старого-то?? (при условии, что система хорошо спроектирована, декомпозиция задачи выполнена грамотно, и т.п.)
AJ>>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?
_>Как обычно. Делаешь объектную декомпозицию задачи, выделяешь классы-участники, для каждого из них пишешь изолированные тесты.
Так вот с этого и надо было начинать Получается, тестировать можно только на уровне микрозадач, которые сами по себе полезной функциональности не представляют.
И при ошибках во взаимодействии этих микрозадач могут возникать ошибки, которые все тесты ни сном ни духом...
Re[4]: Test Driven Development - только для простеньких клас
Здравствуйте, hrg, Вы писали:
hrg>A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :
A>> Здравствуйте, hrg, Вы писали:
hrg>Я вроде в этой эхе расписывал, как это делается. hrg>Вкратце — что такое иерархия элементов — это дерево. У тебя функции hrg>построения дерева. hrg>Берешь кусок документа и строишь для него дерево руками. hrg>Потом запускаешь парсер и смотришь, что он тебе построил. hrg>Если два дерева идентичны — то тест прошел.
Ну да. И все, в чем я могу быть после этого уверен — то, что данный конкретный
документ преобразуется правильно.
Re[3]: Test Driven Development - только для простеньких клас
A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :
A> Здравствуйте, Павел Леонов, Вы писали:
A> Так получается, тесты проверяют лишь минимальную функциональность.
(поперла философия Тесты проверяют только то, что ты написал. Тесты не
явлются мыслящим существом и тем более не обладают телепатическим даром.
Тесты не увеличивают радиус кривизны рук
A> Типа, "по крайней мере в одном случае (чаще всего простейшем) оно A> работает!"
Напиши граничные тесты, там где этот случай работать не должен.
A> Ну тогда не надо называть это тестами. Менее бы вводило в заблуждение A> что-нибудь вроде "иллюстрации простейшего использования"
Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...
Posted via RSDN NNTP Server 1.9 beta
Re[5]: Test Driven Development - только для простеньких клас
A.J. -> "Re[4]: Test Driven Development — только для простеньких клас" :
hrg>> Я вроде в этой эхе расписывал, как это делается. hrg>> Вкратце — что такое иерархия элементов — это дерево. У тебя hrg>> функции построения дерева. hrg>> Берешь кусок документа и строишь для него дерево руками. hrg>> Потом запускаешь парсер и смотришь, что он тебе построил. hrg>> Если два дерева идентичны — то тест прошел.
A> Ну да. И все, в чем я могу быть после этого уверен — то, что данный A> конкретный документ преобразуется правильно.
Здравствуйте, hrg, Вы писали:
hrg>A.J. -> "Re[2]: Test Driven Development — только для простеньких клас" :
A>> Здравствуйте, Павел Леонов, Вы писали:
A>> Так получается, тесты проверяют лишь минимальную функциональность.
hrg>(поперла философия
Ну так названия форума подходящее
hrg>Тесты проверяют только то, что ты написал. Тесты не hrg>явлются мыслящим существом и тем более не обладают телепатическим даром. hrg>Тесты не увеличивают радиус кривизны рук
Ну, я тоже телепатическим даром не обладаю. Я, конечно, могу придумать несколько
ситуаций, когда мое решение _возможно_ не сработает.
Но хочется ведь помечтать о взаимнооднозначном отношении
требование — набор тестов.
Т.е. если набор тестов проходит, то можно быть на 100% уверенным, что требование
выполняется. Так для простых требований это выполняется — написать такие тесты особой проблемы не представляет.
А вот для сложных, составных требований, включающих в себя как правило совместную работу нескольких классов...
Re[2]: Test Driven Development - только для простеньких клас
Здравствуйте, Kapany3, Вы писали:
K>Может тут есть что интересного:
K>http://weblogs.asp.net/wallen/
K>Practical Testing K>Len Holgate is writing a series of posts on Unit Testing with a non-trivial example. Good stuff, check it out.
Похоже как раз то, что надо Спасибо
Re[4]: Test Driven Development - только для простеньких клас
X>> А я всегда считал, что от перемены мест слагаемых сумма не X>> меняется... X>> Объем кода теста, имхо, не очень зависит от того, когда я его буду X>> писать — до или после написания тестируемого кода.
X>> То, что предлагается — по сути размазать написание тестов по всему X>> процессу создания программы — на мой скромный взгляд, является всего X>> лишь неким психологическим самообманом
hrg>Ну как тебе сказать. В традиционном понимании мы начинаем писать прогу, в hrg>уме представляя, что она должна делать. А тут ты сначала пишешь, что на hrg>должна делать (можно прям сценарий из use-case'a выдирать), а потом пишешь hrg>реализацию этого.
Лично я, когда начинаю прогу писать, не use-case-ами мыслю. Это только если совсем тяжко и туго — на примерах разбираю, что и как должно быть. А в основном пытаюсь мыслить максимально абстрактно. Таким вот образом TDD и вступает в противоречие с моим ходом мыслей (и не только с моим, на сколько я знаю). В том смысле, что любой тест — это по сути, как уже было отмечено выше, проверка работы на каком-то конкретном примере (use-case), а мыслю я далеко не конкретными примерами.
А по скольку я искренне уверен, чно нормальный программист должен мыслить именно так как я, то и считаю TDD неадекватной методой....
Не в том смысле, что тестировать не надо, а в том смылсе, что тесты не являются первичными при разработке Это неестественно.
X>> А тот ворох религиозно-политико-идеологических фраз, который X>> заставляют заучивать всех новичков, например
hrg>Тут тоже есть свои причины. Можно долго и пространно объяснять, что, почему, hrg>как, по какой причине, а можно просто сказать: "Будешь делать не так, hrg>убунах".
Немогу не согласится. Вот только нужно быть 1000 раз увереным в своей правоте перед тем как произносить такие фразы с бубнами.
ПЛ>>> Я думаю при таком подходе поднимается вопрос "А что же на самом ПЛ>>> деле я хочу сделать/достичь?"
X>> ... это прямо как заклинания, вводящие новичка в транс, чтобы он X>> поверил в то, что сумма от перемены мест слагаемых таки изменится
hrg>т.е. для тебя важнее процесс, чем резальтат?
Ой! Тут я ничего не буду отвечать, потому что во-первых не просёк логики твоего вопроса (видимо он следует из моей последней процитированной фразы, но я не понимаю как ), а во-вторых, потому что и сам не знаю что для меня важнее
Я желаю и от того и от другого удовольствие получать. В общем-то и получаю
Тесты проверяют только то, что ты написал. Тесты не