Здравствуйте, Eugene Beschastnov, Вы писали:
EB>О, кстати, еще один аргумент против использования файлового diff-а для unit-тестов: очень вероятна рассинхронизация кода и эталона. Да и автоматизированный рефакторинг осложняется. Скажем, захотел я изменить структуру возвращаемого объекта (переименовать, например, что-нибудь) — тогда при использовании assert-ов рефакторинг сможет пройти автоматически, а при использовании файлов — нет.
1. F5 — прогоняешь тесты, ГУИ среда выдаёт список всех отличающихся эталонов
2. кнопкой "вниз" пробегаешь по ним по всем (справа сразу отображается diff) — убеждаешься что всё в порядке, поменялось тольео то что ожидалось
3. Ctrl+A (выбрать все результаты)
3. Ctrl+F (переписать результаты вместо эталонов)
Здравствуйте, Lloyd, Вы писали:
V>>не так уж и много за столько преимуществ L>Да в чем преимущества-то?
я их уже перечислял..
1. меньше тестов
2. можно менять одним махом сразу много эталонных образцов
3. скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе)
4. поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов
от скриптов до хранимых процедур в СУБД
5. можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга
(а то один тест дурной как положит в корку и себя и framework)
6. вообще, можно тестировать даже поток управления таким образом..
Здравствуйте, vvaizh, Вы писали:
V>я их уже перечислял..
V>1. меньше тестов V>2. можно менять одним махом сразу много эталонных образцов V>3. скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе) V>4. поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов V>от скриптов до хранимых процедур в СУБД V>5. можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга V>(а то один тест дурной как положит в корку и себя и framework) V>6. вообще, можно тестировать даже поток управления таким образом..
А ты не путаешь модульное тестирование (unit test) с каким-нибудь другим способом тестирования (регрессионным тестированием или приемочным тестированием)? ИМХО твое описание больше подходит для них.
Здравствуйте, _ALeRT_, Вы писали:
_AL>А ты не путаешь модульное тестирование (unit test) с каким-нибудь другим способом тестирования (регрессионным тестированием или приемочным тестированием)? ИМХО твое описание больше подходит для них.
Вообще говоря конечно путаница есть
подход с диффами можно использовать и как unit-тестирование и как регрессионное и
как функциональное-приёмочное (т.е. вообще например тестовую утилиту как единую программу запускать)
просто unit-тесты наиболее узнаваемое словосочетание из всего вышеперечисленного , поэтому я использовал это название
ну и вообще я всё равно не вижу, почему такой подход хуже подхода с Assert-ами..
Здравствуйте, vvaizh, Вы писали:
V>я их уже перечислял..
V>1. меньше тестов
Как этот подход уменьшит кол-во тестов?
V>2. можно менять одним махом сразу много эталонных образцов
Нука-нука. Расскажи как? И почему то же самое нельзя делать с нормальными тестами.
V>3. скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе)
Набросай побыстрому как ты будешь сравнивать два датасета, например.
V>4. поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов V>от скриптов до хранимых процедур в СУБД
поскольку код-понятие которое есть везде, ...
V>5. можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга V>(а то один тест дурной как положит в корку и себя и framework)
Не вопрос. Заускай тесты поштучно.
V>6. вообще, можно тестировать даже поток управления таким образом..
Здравствуйте, vvaizh, Вы писали:
V>ну и вообще я всё равно не вижу, почему такой подход хуже подхода с Assert-ами.
ИМХО он не хуже, он просто другой и предназначен для других целей. Например внутренную функциональность часто удобнее проверять с помощью Assert'ов, так как с ними тест получается не такой громоздкий и его легче менять, рефакторить и т.д. Подход с diff'ом удобнее для тестирования (регрессионного или приемочного) системы в целом. В этом случаее тест обычно не меняется и в нем содержится большое колличество проверок, которые часто неудобно делать через Assert'ты.
Здравствуйте, _ALeRT_, Вы писали:
V>>ну и вообще я всё равно не вижу, почему такой подход хуже подхода с Assert-ами. _AL>ИМХО он не хуже, он просто другой и предназначен для других целей. Например внутренную функциональность часто удобнее проверять с помощью Assert'ов, так как с ними тест получается не такой громоздкий и его легче менять, рефакторить и т.д.
При достаточно большой системе тестов ИМХО это удобство практически совсем теряется
Здравствуйте, vvaizh, Вы писали:
V>При достаточно большой системе тестов ИМХО это удобство практически совсем теряется
Ну удобство — это конечно (в данном случае) вопрос вкуса. Лично я считаю, что даже в большой системе тестов сами тесты (которые unit tests) должны быть не большие (как функции — не больше экрана), а дальше — это вопрос качества кода (ИМХО должно быть удобно).
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
V>>я их уже перечислял..
V>>1. меньше тестов L>Как этот подход уменьшит кол-во тестов?
ну как как.. за счёт того что сразу много параметров можно пихать, и правильно разруливать какой из них глючит..
V>>2. можно менять одним махом сразу много эталонных образцов L>Нука-нука. Расскажи как? И почему то же самое нельзя делать с нормальными тестами.
потому что в случае с выводом первых результатов Assert-ов в файл я могу простым копированием результирующего файал поверх эталонного поменять все эталоны, в которых например поменялась большая буква на маленькую
а в случае Assert-ов я должен буду бегать по коду и менять в каждом ассерте большую букву на маленькую..
V>>3. скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе) L>Набросай побыстрому как ты будешь сравнивать два датасета, например.
сделаю им xml-сериализацию (да хоть soap-вскую)
отформатирую так, чтобы каждое поле в отдельной строке было (XmlTestWriter с включенным Formatting-ом)
да и выкину в результирующий файл..
между прочим внутренние тесты mysql как я уже упомянал выше примерно так и устроены..
они именно датасеты и сравнивают! как тексты.. diff-ом..
V>>4. поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов V>>от скриптов до хранимых процедур в СУБД
L>поскольку код-понятие которое есть везде, ...
дык код то разный.. для разных языков..
нет пока для всех языков общей среды тестирования..
для java- отдельно
для .NET — отдельно
для smaltalk — отдельно
и т.п.
а тут можно общую забабашить
V>>5. можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга V>>(а то один тест дурной как положит в корку и себя и framework) L>Не вопрос. Заускай тесты поштучно.
по умолчанию они вместе запускаются
V>>6. вообще, можно тестировать даже поток управления таким образом.. L>Подробнее, что ты имеешь в виду.
я имею ввиду trace программы..
который можно сравнивать с эталонным..
ну или log выполнения, как тебе понятнее..
Здравствуйте, _ALeRT_, Вы писали:
_AL>Здравствуйте, vvaizh, Вы писали:
V>>При достаточно большой системе тестов ИМХО это удобство практически совсем теряется
_AL>Ну удобство — это конечно (в данном случае) вопрос вкуса. Лично я считаю, что даже в большой системе тестов сами тесты (которые unit tests) должны быть не большие (как функции — не больше экрана), а дальше — это вопрос качества кода (ИМХО должно быть удобно).
Ну хорошо, а есть ли вообще системы которые автоматизируют тесты на основе diff-а?
и почему их видимо гораздо меньше чем xunit-вых систем?
Здравствуйте, vvaizh, Вы писали:
V>Ну хорошо, а есть ли вообще системы которые автоматизируют тесты на основе diff-а? V>и почему их видимо гораздо меньше чем xunit-вых систем?
Системы, с которыми я знаком основанны на Assert'тах. На сколько я понимаю на основе такой системы не сложно написать простой вариант системы тестирования на основе diff-а. Как-то мне попадалась система (http://fit.c2.com/wiki.cgi?IntroductionToFit), похожая на то о чем ты говоришь, но я в ней глубоко не разбирался.
Здравствуйте, vvaizh, Вы писали:
V>>>1. меньше тестов L>>Как этот подход уменьшит кол-во тестов?
V>ну как как.. за счёт того что сразу много параметров можно пихать, и правильно разруливать какой из них глючит..
Напиши функцию, кот сделать то же самое.
L>>Нука-нука. Расскажи как? И почему то же самое нельзя делать с нормальными тестами.
V>потому что в случае с выводом первых результатов Assert-ов в файл я могу простым копированием результирующего файал поверх эталонного поменять все эталоны, в которых например поменялась большая буква на маленькую
V>вообще, посмотри тут: V>http://izh-test.sourceforge.net/advantege_1.html
V>а в случае Assert-ов я должен буду бегать по коду и менять в каждом ассерте большую букву на маленькую..
Не аргумент.
V>>>3. скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе) L>>Набросай побыстрому как ты будешь сравнивать два датасета, например.
V>сделаю им xml-сериализацию (да хоть soap-вскую) V>отформатирую так, чтобы каждое поле в отдельной строке было (XmlTestWriter с включенным Formatting-ом)
V>да и выкину в результирующий файл..
V>между прочим внутренние тесты mysql как я уже упомянал выше примерно так и устроены.. V>они именно датасеты и сравнивают! как тексты.. diff-ом..
То есть молимся, чтобы датасет не дай бог переставит строчки?
V>>>4. поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов V>>>от скриптов до хранимых процедур в СУБД
L>>поскольку код-понятие которое есть везде, ...
V>дык код то разный.. для разных языков.. V>нет пока для всех языков общей среды тестирования.. V>для java- отдельно V>для .NET — отдельно V>для smaltalk — отдельно V>и т.п.
V>а тут можно общую забабашить
Не забабашиш. Просто вводишь дополнительное звено. Тесты-то все-равно пишутся на прежнем языке.
V>>>5. можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга V>>>(а то один тест дурной как положит в корку и себя и framework) L>>Не вопрос. Заускай тесты поштучно.
V>по умолчанию они вместе запускаются
Твои тесты по умолчанию у меня вообще не работают, ибо не стоят
V>>>6. вообще, можно тестировать даже поток управления таким образом.. L>>Подробнее, что ты имеешь в виду.
V>я имею ввиду trace программы.. V>который можно сравнивать с эталонным.. V>ну или log выполнения, как тебе понятнее..
Боюсь, без модификации кода программы это не так-то легко сделать.
Здравствуйте, Lloyd, Вы писали:
V>>>>1. меньше тестов L>>>Как этот подход уменьшит кол-во тестов? V>>ну как как.. за счёт того что сразу много параметров можно пихать, и правильно разруливать какой из них глючит.. L>Напиши функцию, кот сделать то же самое.
мне нужно на каждый такой случай функцию писать, думать..
потом будет много функций, а тут — универсальный подход позволяющий не напрягать особо мозги..
L>>>Нука-нука. Расскажи как? И почему то же самое нельзя делать с нормальными тестами. V>>потому что в случае с выводом первых результатов Assert-ов в файл я могу простым копированием результирующего файал поверх эталонного поменять все эталоны, в которых например поменялась большая буква на маленькую V>>вообще, посмотри тут: V>>http://izh-test.sourceforge.net/advantege_1.html V>>а в случае Assert-ов я должен буду бегать по коду и менять в каждом ассерте большую букву на маленькую.. L>Не аргумент.
аргумент
V>>сделаю им xml-сериализацию (да хоть soap-вскую) V>>отформатирую так, чтобы каждое поле в отдельной строке было (XmlTestWriter с включенным Formatting-ом) V>>да и выкину в результирующий файл..
L>То есть молимся, чтобы датасет не дай бог переставит строчки?
ставим сортировку явную, если такое возможно..
V>>а тут можно общую забабашить L>Не забабашиш. Просто вводишь дополнительное звено. Тесты-то все-равно пишутся на прежнем языке.
да, но они могут не подключать никаких дополнительных библиотек например..
для тех же хранимых прцедур это актуально..
да и вообще, нативную среду одну на всех написать да и не парится..
V>>по умолчанию они вместе запускаются L>Твои тесты по умолчанию у меня вообще не работают, ибо не стоят
дык и NUnit и JUnit нужно ставить..
V>>я имею ввиду trace программы.. V>>который можно сравнивать с эталонным.. V>>ну или log выполнения, как тебе понятнее.. L>Боюсь, без модификации кода программы это не так-то легко сделать.
ну во первых большинство сложных программ и так имеют развитую систему логов
а во вторых что с того что просто..
Здравствуйте, _ALeRT_, Вы писали:
_AL>Системы, с которыми я знаком основанны на Assert'тах. На сколько я понимаю на основе такой системы не сложно написать простой вариант системы тестирования на основе diff-а.
до определённого момента я тоже именно так и делал
заводил в NUnit-ах что то вроде файлового ассерта
но много времени уходило на анализ того чем отличаются файлы, копирование одного поверх другого и т.п.
среда NUnit тестов этого не позволяет..
вот в общем то тогда и написал http://sourceforge.net/projects/izh-test/
сейчас наоборот зачастую NUnit тесты не пишу, а пишу в ней
например есть у меня в рабочей программе пользовательская функция,
которая готовит некоторую информацию в виде пары xml-файлов
добавляет к ним отчёт в html формате, всё это пакует zip-ом для передачи дальше по почте
ну и как мне это в NUnit-ах тестировать ?
а для izh_test я просто написал консольную утилитку которая нужный файл готовит
izh_test сама эту утилитку вызывает, распаковывает файлы, показывает мне результат и
сравнивает с эталоном
_AL>Как-то мне попадалась система (http://fit.c2.com/wiki.cgi?IntroductionToFit), похожая на то о чем ты говоришь, но я в ней глубоко не разбирался.
да, идея похожа
но использование вордовского файла мне не внушает надежды
Здравствуйте, vvaizh, Вы писали:
V>Здравствуйте, Lloyd, Вы писали:
V>>>>>1. меньше тестов L>>>>Как этот подход уменьшит кол-во тестов? V>>>ну как как.. за счёт того что сразу много параметров можно пихать, и правильно разруливать какой из них глючит.. L>>Напиши функцию, кот сделать то же самое.
V>мне нужно на каждый такой случай функцию писать, думать.. V>потом будет много функций, а тут — универсальный подход позволяющий не напрягать особо мозги..
А код сериализации в файл у тебя зам появляется?
L>>Не аргумент.
V>аргумент
Для меня — нет.
V>>>сделаю им xml-сериализацию (да хоть soap-вскую) V>>>отформатирую так, чтобы каждое поле в отдельной строке было (XmlTestWriter с включенным Formatting-ом) V>>>да и выкину в результирующий файл..
L>>То есть молимся, чтобы датасет не дай бог переставит строчки?
V>ставим сортировку явную, если такое возможно..
Ну вот, начинается. Но что не сделаешь чтобы в фало записать и дифом воспользоваться.
V>>>а тут можно общую забабашить L>>Не забабашиш. Просто вводишь дополнительное звено. Тесты-то все-равно пишутся на прежнем языке.
V>да, но они могут не подключать никаких дополнительных библиотек например.. V>для тех же хранимых прцедур это актуально.. V>да и вообще, нативную среду одну на всех написать да и не парится..
Не понял что ты имеешь в виду. Какую среду? Вот пишу я на шарпе, как мне использовать эту "нативную" среду?
V>>>я имею ввиду trace программы.. V>>>который можно сравнивать с эталонным.. V>>>ну или log выполнения, как тебе понятнее.. L>>Боюсь, без модификации кода программы это не так-то легко сделать.
V>ну во первых большинство сложных программ и так имеют развитую систему логов
Приведи, пожалуйста полный список большинства сложных программ, о котором ты говоришь.
P.S. Давай рассмотрим гипотетическую ситуацию. Ты выполняешь какое-то действие и должен проверить что в логе появилась запись. Эта запись должна иметь отметку о времени совершенного действия. Приведи схематичный пример того, как ты это будешь делать с твоим дифом.
Здравствуйте, vvaizh, Вы писали:
V>например есть у меня в рабочей программе пользовательская функция, V>которая готовит некоторую информацию в виде пары xml-файлов V>добавляет к ним отчёт в html формате, всё это пакует zip-ом для передачи дальше по почте
ИМХО unit-test'ы (если мы все еще говорим о них) предназначены, преже всего, для тестирования внутренней логики программы (функции). Для того, чтобы это сделать не нужно выполнять всю ту сложную работу, которую ты описал. В данном случае стоит воспользоваться мок-объектами (mock objects), что позволит достаточно просто протестировать логику самой функции, а не работу всей программы в целом (что гораздо сложнее). Если же ты хочешь протестировать работу программы, то тебе подойдет регрессонное тестирование (оно-то и будет основанно на сравнении файлов).
Здравствуйте, _ALeRT_, Вы писали:
V>>например есть у меня в рабочей программе пользовательская функция, V>>которая готовит некоторую информацию в виде пары xml-файлов V>>добавляет к ним отчёт в html формате, всё это пакует zip-ом для передачи дальше по почте
_AL>ИМХО unit-test'ы (если мы все еще говорим о них) предназначены, преже всего, для тестирования внутренней логики программы (функции). Для того, чтобы это сделать не нужно выполнять всю ту сложную работу, которую ты описал. В данном случае стоит воспользоваться мок-объектами (mock objects), что позволит достаточно просто протестировать логику самой функции, а не работу всей программы в целом (что гораздо сложнее). Если же ты хочешь протестировать работу программы, то тебе подойдет регрессонное тестирование (оно-то и будет основанно на сравнении файлов).
ИМХО тут разделительная грань проходит не между регрессионным и unit тестированием
а между тестированием функций дающих небольшое количество скалярных значений,
и функций, результатом работы которых будет являться сложная аггрегатная структуры.
Вот я в одном проекте убедил людей что нужно использовать NUnit тесты и что..
они просто напросто стали для аггрегатных результатов функций писать проверку на то что это не нулл и всё..
на большее их не хватило
Кароче неважно, внутренняя это функция или это и есть вся программа..
количество ассертов которые приходится писать для тестирования сложной аггрегатной структуры а
также затраты на их сопровождение вполне сравнимо а то больше для Assert-ов чем для файлового сравнения..
кстати абсолютно внешняя нативная среда тут тоже не краеугольный камень..
вполне можно написать библиотеку для .NET когда можно будет писать без всяких внешних описаний в
стиле NUnit, описывая всю логику тестов аттрибутами..
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали: V>>Здравствуйте, Lloyd, Вы писали:
V>>>>>>1. меньше тестов L>>>>>Как этот подход уменьшит кол-во тестов? V>>>>ну как как.. за счёт того что сразу много параметров можно пихать, и правильно разруливать какой из них глючит.. L>>>Напиши функцию, кот сделать то же самое. V>>мне нужно на каждый такой случай функцию писать, думать.. V>>потом будет много функций, а тут — универсальный подход позволяющий не напрягать особо мозги.. L>А код сериализации в файл у тебя зам появляется?
It depends
Для целого ряда вариантов испогльзования он уже есть.. (отчёты, html странички, всякие конверторы)
В любом случае ИМХО печать в текстовый файл писать гораздо проще чем кучу сравнений
L>>>То есть молимся, чтобы датасет не дай бог переставит строчки? V>>ставим сортировку явную, если такое возможно.. L>Ну вот, начинается. Но что не сделаешь чтобы в фало записать и дифом воспользоваться.
целые статьи посвящены тому что нужно делать чтобы использовать NUnit тесты
тоже знаешь ли код часто приходится менять
V>>>>а тут можно общую забабашить L>>>Не забабашиш. Просто вводишь дополнительное звено. Тесты-то все-равно пишутся на прежнем языке.
V>>да, но они могут не подключать никаких дополнительных библиотек например.. V>>для тех же хранимых прцедур это актуально.. V>>да и вообще, нативную среду одну на всех написать да и не парится.. L>Не понял что ты имеешь в виду. Какую среду? Вот пишу я на шарпе, как мне использовать эту "нативную" среду?
на данный момент — писать консольную обвязку, вызывающую внутренние функции
хотя в плане — специальный адаптер, который позволит писать в стиле NUnit с аттрибутами
а загружатся будет "в среду" примерно так же как сейчас в NUnutGUI загружается
V>>>>я имею ввиду trace программы.. V>>>>который можно сравнивать с эталонным.. V>>>>ну или log выполнения, как тебе понятнее.. L>>>Боюсь, без модификации кода программы это не так-то легко сделать. V>>ну во первых большинство сложных программ и так имеют развитую систему логов L>Приведи, пожалуйста полный список большинства сложных программ, о котором ты говоришь.
зачем? полный?
все серверный и коммуникационные программы имеют логи
расчётные программы как правило тоже
многонитевые — как правило
и т.п.
L>P.S. Давай рассмотрим гипотетическую ситуацию. Ты выполняешь какое-то действие и должен проверить что в логе появилась запись. Эта запись должна иметь отметку о времени совершенного действия. Приведи схематичный пример того, как ты это будешь делать с твоим дифом.
ну ввожу как и в NUnit тестах специальный "тестовый" таймер который даёт "тестовое" время
что то вроде такого, но как я понимаю в секундах всё должно быть:
' <summary>тестовый класс для получения текущего времени (при каждом взятии возвращает время на день позже предыдущего)</summary>
Class TestTimeProvider
Implements ITimeProvider
' <summary>счётчик времени</summary>Public count As Integer = 0
' <summary>перезапустить счётчик времени</summary>Public Sub Reset()
count = 0
End Sub' <summary>получить текущее время</summary>Public ReadOnly Property Now() As DateTime Implements ITimeProvider.Now
Get
Dim ncount As Integer
ncount = count
count = count + 1
Return DateTime.Parse("03.02.1976").AddDays(ncount)
End Get
End Property
End Class
Ладно, задолбало спорить. Если тебе так понравился этот метод — исползуй его. Хозяин — барин. Я лично для себя не вижу в нем ничего интересного/полезного. Если будешь использовать, расскажи, что было удобно или неудобно в таком подходе.
, поэтому я использовал это название
