Собственно хочется обсудить почему большинство систем сравнивают
каждое значение в отдельности, в то время как проще и удобнее гораздо сваливать
все первые аргументы Assert.IsEqual() в файл и сравнивать их с эталонным файлом целиком
Тогда и разницу сразу можно посмотреть детально и заменить все эталонные значения на новые,
и со сложными структурами данных проще.
Такой подход идеально подходит для тестирования веб-приложений, отчётов,
всяческих конверторов и т.п. где результатом итак является файл.
Для примера внутренняя система тестов mysql построена именно на сравнении файлов.
Хотя опять же внутрення система тестирования mysql-кластера, такого же по классу проекта
построена на Assert-ах.
Здравствуйте, vvaizh, Вы писали:
V>Собственно хочется обсудить почему большинство систем сравнивают V>каждое значение в отдельности, в то время как проще и удобнее гораздо сваливать V>все первые аргументы Assert.IsEqual() в файл и сравнивать их с эталонным файлом целиком
А какое сообщение nunit-а вас больше удовлетворит: Приложение работает неправильно, или Стоимость рассчитывается некорректно?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
V>>Собственно хочется обсудить почему большинство систем сравнивают V>>каждое значение в отдельности, в то время как проще и удобнее гораздо сваливать V>>все первые аргументы Assert.IsEqual() в файл и сравнивать их с эталонным файлом целиком
L>А какое сообщение nunit-а вас больше удовлетворит: Приложение работает неправильно, или Стоимость рассчитывается некорректно?
меня удовлетворит сообщение в виде diff-а двух файлов который укажет конкретное место, которое неправильное, в вашем конкретном случае я увижу как раз стоимость..
C:\tmp>fc test.etalon.txt test.result.txt
Сравнение файлов test.etalon.txt и TEST.RESULT.TXT
***** test.etalon.txt
Вопросы с подковыркой : 1
Стоимость : 0
Готовые ответы : 1
***** TEST.RESULT.TXT
Вопросы с подковыркой : 1
Стоимость : 1 000 000 000
Готовые ответы : 1
*****
кроме того, если писать в файл, то можно получить не только стоимость но и вообще все отличающиеся значения
традиционные же unit-test ы вылетят сразу на стоимости, и чтобы узнать что ещё в тесте неправильно нужно будет сначала со стоимостью разобраться..
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>Потому что файловый diff гораздо сложнее интегрировать в IDE (дебаггер, быстрая навигация по коду и т.д.), чем assert-ы.
Вообще говоря свежая мысль, как то об этом не думал..
(Я и nunit-ами пользуюсь не интегрируя их в среду)
Имеется в виду, что ассерт сразу покажет проблемную строчку кода?
тут несколько ответов:
1. проблема как правило всё равно совсем не в той строке кода, которая проверяет, а в той, которая меняет..
2. в теории можно предложить дописывать в строчку в файл и координаты строки кода, который сформировал эту строку, тогда можно будет и интегрировать нормально..
Здравствуйте, vvaizh, Вы писали:
L>>А какое сообщение nunit-а вас больше удовлетворит: Приложение работает неправильно, или Стоимость рассчитывается некорректно?
V>меня удовлетворит сообщение в виде diff-а двух файлов который укажет конкретное место, которое неправильное, в вашем конкретном случае я увижу как раз стоимость..
И зачем эта простыня верных значений. Человека запускающего тест это не должно интересовать. Ему важно лишь на чем упали тесты.
V>кроме того, если писать в файл, то можно получить не только стоимость но и вообще все отличающиеся значения V>традиционные же unit-test ы вылетят сразу на стоимости, и чтобы узнать что ещё в тесте неправильно нужно будет сначала со стоимостью разобраться..
Нет, не надо будет, если у вас тесты проверяют не все и сразу, а только стоимость.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
L>>>А какое сообщение nunit-а вас больше удовлетворит: Приложение работает неправильно, или Стоимость рассчитывается некорректно?
V>>меня удовлетворит сообщение в виде diff-а двух файлов который укажет конкретное место, которое неправильное, в вашем конкретном случае я увижу как раз стоимость..
L>Так стоимость и есть неправильное значение. Куда ж конкретнее?
конкретнее в случае unit-test ов это увидеть не только что стоимость неправильная а увидеть конкретно почему она неправильная и при каких других значениях.. например составляющих этой стоимости..
V>>графически это выглядит примерно так:
V>>http://sourceforge.net/project/screenshots.php?group_id=171639
L>И зачем эта простыня верных значений. Человека запускающего тест это не должно интересовать. Ему важно лишь на чем упали тесты.
нормальный человек кинется проверять условия при котором посчиталась неверная стоимость, может быть посмотрит стоимость которая была скажем на предыдущей итерации и т.п.
файл и дифф всё это ему наглядно показывает..
это как stack-trace..
не будете же вы утверждать что и stack-trace не нужен а нужна лишь строка в которой упало..
V>>кроме того, если писать в файл, то можно получить не только стоимость но и вообще все отличающиеся значения V>>традиционные же unit-test ы вылетят сразу на стоимости, и чтобы узнать что ещё в тесте неправильно нужно будет сначала со стоимостью разобраться..
L>Нет, не надо будет, если у вас тесты проверяют не все и сразу, а только стоимость.
вырожденные случаи давайте откинем и будем рассматривать практические насущные потребности программистов..
а то мне что то пока не заказывали программу которая ничего кроме стоимости не считает..
Здравствуйте, vvaizh, Вы писали:
EB>>Потому что файловый diff гораздо сложнее интегрировать в IDE (дебаггер, быстрая навигация по коду и т.д.), чем assert-ы.
V>Вообще говоря свежая мысль, как то об этом не думал.. V>(Я и nunit-ами пользуюсь не интегрируя их в среду)
V>Имеется в виду, что ассерт сразу покажет проблемную строчку кода? V>тут несколько ответов:
V>1. проблема как правило всё равно совсем не в той строке кода, которая проверяет, а в той, которая меняет.. V>2. в теории можно предложить дописывать в строчку в файл и координаты строки кода, который сформировал эту строку, тогда можно будет и интегрировать нормально..
Насчёт nunit не знаю, но, например, в Smalltalk при провалившемся assert-е вываливаешься в дебаггер, а там можно посмотреть абсолютно всё, что захочешь, а заодно сразу исправить и прогнать тест заново.
Здравствуйте, vvaizh, Вы писали:
V>конкретнее в случае unit-test ов это увидеть не только что стоимость неправильная а увидеть конкретно почему она неправильная и при каких других значениях.. например составляющих этой стоимости..
Ну так выведи в Assert всю информацию которая тебе нужно и будет тебе счастье.
L>>И зачем эта простыня верных значений. Человека запускающего тест это не должно интересовать. Ему важно лишь на чем упали тесты.
V>нормальный человек кинется проверять условия при котором посчиталась неверная стоимость, может быть посмотрит стоимость которая была скажем на предыдущей итерации и т.п.
Не знаю что ты имеешь в виду под итерацией, но если это предыдущий запуск теста, то проблема явно надуманная, т.к. в предыдущий раз цена была равна тому, что у тебя прописано в Assert-е.
V>файл и дифф всё это ему наглядно показывает.. V>это как stack-trace..
Неверная аналогия.
L>>Нет, не надо будет, если у вас тесты проверяют не все и сразу, а только стоимость.
V>вырожденные случаи давайте откинем и будем рассматривать практические насущные потребности программистов.. V>а то мне что то пока не заказывали программу которая ничего кроме стоимости не считает..
Будь внимательнее. Я не писал тебе что программа должна считать только стоимость, я написал, что тест должен проверять не все сразу, а то что стоимость считается корректно.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
V>>конкретнее в случае unit-test ов это увидеть не только что стоимость неправильная а увидеть конкретно почему она неправильная и при каких других значениях.. например составляющих этой стоимости..
L>Ну так выведи в Assert всю информацию которая тебе нужно и будет тебе счастье.
L>>>И зачем эта простыня верных значений. Человека запускающего тест это не должно интересовать. Ему важно лишь на чем упали тесты.
V>>нормальный человек кинется проверять условия при котором посчиталась неверная стоимость, может быть посмотрит стоимость которая была скажем на предыдущей итерации и т.п.
L>Не знаю что ты имеешь в виду под итерацией, но если это предыдущий запуск теста, то проблема явно надуманная, т.к. в предыдущий раз цена была равна тому, что у тебя прописано в Assert-е.
это не предыдущий запуск теста
это стоимость например для предыдущего месяца
V>>файл и дифф всё это ему наглядно показывает.. V>>это как stack-trace..
L>Неверная аналогия.
а по моему дык как раз верная..
что ты будешь делать когда увидишь что баланс не сошёлся?
смотреть конкретные счета..
L>>>Нет, не надо будет, если у вас тесты проверяют не все и сразу, а только стоимость.
V>>вырожденные случаи давайте откинем и будем рассматривать практические насущные потребности программистов.. V>>а то мне что то пока не заказывали программу которая ничего кроме стоимости не считает..
L>Будь внимательнее. Я не писал тебе что программа должна считать только стоимость, я написал, что тест должен проверять не все сразу, а то что стоимость считается корректно.
ИМХО такой подход как раз является причиной того что TDD до сих пор мало распространено "в народе"
Потому что не каждому хватит терпения прописывать Assert-ы для каждого элемента сложных структур
которые получаются на выходе..
Вообще, не понятна проблема..
Во главе угла ИМХО должно стоять удобство использования для программиста, а не то что вот конкретный тест для конкретного одного единственного значения..
давай лучше рассмотрим конкретный пример в котором удобнее традиционный Assert? я пока такого тут не вижу
вообще утверждение какое то логически неполное..
из того что тест проверяет всё сразу как раз следует что он проверяет и стоимость..
в чём проблема?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
V>>конкретнее в случае unit-test ов это увидеть не только что стоимость неправильная а увидеть конкретно почему она неправильная и при каких других значениях.. например составляющих этой стоимости..
L>Ну так выведи в Assert всю информацию которая тебе нужно и будет тебе счастье.
ага..
в один и тот же Assert?
или в разные?
если в один и тот же то получится как раз твоё "значения не совпадают"..
в лучшем случае укажет с какого места они не совпадает..
если же в несколько ассертов, то упадёт всё равно на первом
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>Здравствуйте, vvaizh, Вы писали:
EB>>>Потому что файловый diff гораздо сложнее интегрировать в IDE (дебаггер, быстрая навигация по коду и т.д.), чем assert-ы.
V>>Вообще говоря свежая мысль, как то об этом не думал.. V>>(Я и nunit-ами пользуюсь не интегрируя их в среду)
V>>Имеется в виду, что ассерт сразу покажет проблемную строчку кода? V>>тут несколько ответов:
V>>1. проблема как правило всё равно совсем не в той строке кода, которая проверяет, а в той, которая меняет.. V>>2. в теории можно предложить дописывать в строчку в файл и координаты строки кода, который сформировал эту строку, тогда можно будет и интегрировать нормально..
EB>Насчёт nunit не знаю, но, например, в Smalltalk при провалившемся assert-е вываливаешься в дебаггер, а там можно посмотреть абсолютно всё, что захочешь, а заодно сразу исправить и прогнать тест заново.
Здравствуйте, vvaizh, Вы писали:
L>>Не знаю что ты имеешь в виду под итерацией, но если это предыдущий запуск теста, то проблема явно надуманная, т.к. в предыдущий раз цена была равна тому, что у тебя прописано в Assert-е.
V>это не предыдущий запуск теста V>это стоимость например для предыдущего месяца
Мне кажется ты неверно понимаешь что такое тест. Такого типа проверки тест делать не должен (imho).
V>давай лучше рассмотрим конкретный пример в котором удобнее традиционный Assert? я пока такого тут не вижу
Давай лучше рассмотрим чем твой подход учше.
V>вообще утверждение какое то логически неполное.. V>из того что тест проверяет всё сразу как раз следует что он проверяет и стоимость.. V>в чём проблема?
Не, из этого следует другой вывод. Если он проверят все и сразу, то значит этот тест сложный, а сложность — ф топпку.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vvaizh, Вы писали:
L>>>Не знаю что ты имеешь в виду под итерацией, но если это предыдущий запуск теста, то проблема явно надуманная, т.к. в предыдущий раз цена была равна тому, что у тебя прописано в Assert-е.
V>>это не предыдущий запуск теста V>>это стоимость например для предыдущего месяца
L>Мне кажется ты неверно понимаешь что такое тест. Такого типа проверки тест делать не должен (imho).
Он не должен такого делать как раз из-за ограниченности подхода с Assert-ами..
Для программиста ИМХО как раз удобнее чтобы он такие проверки делал..
Это уменьшит затраты на написание тестов и увеличит эффективность их использования
V>>давай лучше рассмотрим конкретный пример в котором удобнее традиционный Assert? я пока такого тут не вижу L>Давай лучше рассмотрим чем твой подход учше.
меньше тестов
можно менять одним махом сразу много эталонных образцов
скинув данные в файл можно проверять значения не скалярные а сложные аггрегатные (например всю результирующую html-страничку разом, или rtf-отчёт, или вообще любой файл на выходе)
поскольку файл — понятие которое есть везде можно реализовать систему так что среда будет позволять единообразное тестирование всех компонентов
от скриптов до хранимых процедур в СУБД
можно запускать тесты как отдельные прцессы и таким образом надёжно изолировать их друг от друга
(а то один тест дурной как положит в корку и себя и framework)
вообще, можно тестировать даже поток управления таким образом..
V>>вообще утверждение какое то логически неполное.. V>>из того что тест проверяет всё сразу как раз следует что он проверяет и стоимость.. V>>в чём проблема?
L>Не, из этого следует другой вывод. Если он проверят все и сразу, то значит этот тест сложный, а сложность — ф топпку.
ну вообще говоря это означает что один "сложный" тест ты заменяешь сотней маленьких
при том что сложный тест даёт те же результаты что и твоя сотня..
вообще так послушать дык можно прийти к тому что на один тест должен быть один Assert.IsEqual, а иначе это уже сложный тест..
Здравствуйте, vvaizh, Вы писали:
L>>Мне кажется ты неверно понимаешь что такое тест. Такого типа проверки тест делать не должен (imho).
V>Он не должен такого делать как раз из-за ограниченности подхода с Assert-ами.. V>Для программиста ИМХО как раз удобнее чтобы он такие проверки делал.. V>Это уменьшит затраты на написание тестов и увеличит эффективность их использования
Скажи, пожалуйста, как ты считаешь, что должен делать тест?
L>>Не, из этого следует другой вывод. Если он проверят все и сразу, то значит этот тест сложный, а сложность — ф топпку.
V>ну вообще говоря это означает что один "сложный" тест ты заменяешь сотней маленьких V>при том что сложный тест даёт те же результаты что и твоя сотня..
V>вообще так послушать дык можно прийти к тому что на один тест должен быть один Assert.IsEqual, а иначе это уже сложный тест..
Здравствуйте, Lloyd, Вы писали:
L>Скажи, пожалуйста, как ты считаешь, что должен делать тест?
да много чего
1. проверять соответствие того что программа делает тому что ожидается
2. помогать программистам находить ошибки
3. проверять отсутствие появления новых "побочных" ошибок в уже вроде бы отлаженом куске кода от изменений в другом куске
да вообще можно взять Фаулера да почитать
ну или ещё кого нибудь
Здравствуйте, vvaizh, Вы писали:
V>ага.. V>в один и тот же Assert? V>или в разные? V>если в один и тот же то получится как раз твоё "значения не совпадают".. V>в лучшем случае укажет с какого места они не совпадает..
V>если же в несколько ассертов, то упадёт всё равно на первом
Если тебе хочется сверить все значения в структуре, то напиши функцию проверяющую на равенство и вызови Assert.IsTrue и будет тебе счастье. В файло-то зачем пихать?
Здравствуйте, Lloyd, Вы писали:
L>Если тебе хочется сверить все значения в структуре, то напиши функцию проверяющую на равенство и вызови Assert.IsTrue и будет тебе счастье. В файло-то зачем пихать?
потому что :
1. функции сравнения файлов уже написаны
2. есть не только функции сравнения файлов, а ещё и функции нахождения diff-а между файлами.. то есть я увижу конкретные элементы структуры которые "не совпадают"
3. чтобы сравнить структу со структурой нужно эту эталонную структуру ещё заполнить/подготовить..
а с файлом всё просто..
один раз тест прогнал, получил результат..
посмотрел глазками что вроде как всё правильно, все поля совпадают..
заменил эталонный файл результирующим и всё..
гораздо проще чем описывать каждый раз сложный эталон в коде
а если вдруго понадобится эталон менять, то это опять же гораздо проще сделать
переписав файл-результат поверх эталонного..
Здравствуйте, vvaizh, Вы писали:
V> а с файлом всё просто.. V> один раз тест прогнал, получил результат.. V> посмотрел глазками что вроде как всё правильно, все поля совпадают.. V> заменил эталонный файл результирующим и всё.. V> гораздо проще чем описывать каждый раз сложный эталон в коде V> а если вдруго понадобится эталон менять, то это опять же гораздо проще сделать V> переписав файл-результат поверх эталонного..
О, кстати, еще один аргумент против использования файлового diff-а для unit-тестов: очень вероятна рассинхронизация кода и эталона. Да и автоматизированный рефакторинг осложняется. Скажем, захотел я изменить структуру возвращаемого объекта (переименовать, например, что-нибудь) — тогда при использовании assert-ов рефакторинг сможет пройти автоматически, а при использовании файлов — нет.
