GlebZ wrote:
> E>Какую байду с тестированием? VERIFY из релиза выкидывается, а
> вычисление подскобочного выражения остается
> К тебе приходит результат функции в виде структуры с 3 полями. Ты их
> хочешь проверить. Ты будешь поднимать VERIFY?
Надо быть проще

std::pair<int,int> some=some_func(...);
assert(some.first==1);
assert(some.second==2);

Здравствуйте, GlebZ, Вы писали:

E>>Какую байду с тестированием? VERIFY из релиза выкидывается, а вычисление подскобочного выражения остается
GZ>К тебе приходит результат функции в виде структуры с 3 полями. Ты их хочешь проверить. Ты будешь поднимать VERIFY?

Тебе не кажется, что ты уводишь разговор в сторону? Ты привел пример неудачного использования ASSERT, тогда, когда нужно было использовать VERIFY, под видом того, что ASSERT — зло. Я обратил твое внимание на это.

Теперь приводишь непонятный пример со структурой, которая никакого отношения к предыдущему разговору не имеет.

Проверять или не проверять поля этой структуры и где их проверять, если их надо проверять — зависит от задачи. Если невалидные значения допускаются логикой программы, то вариантов может быть много — от комбинаций ASSERT-ов и выброса исключений до корректирования полей этой структуры. Если невалидные значения по логике недопустимы, то ASSERT (при чем тут спршивается VERIFY и где я говорил о том что буду использовать VERIFY ):

void process(MyStruct s) {
    ASSERT(s.x >= 0);
    ASSERT(s.y <= 5);
    ASSERT(s.z == 0);
    // ...
}

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

A>>Если код не протестирован, то как можно говорить о том, что он работает правильно?
LCR>Очень даже можно. Как я и говорил, убедиться в том, что он работает, можно наличием другого тестирования. Проверяются все варианты использования, какие нужны, а работа программы при -273'C не требуется. Предлагаешь вместо создания руля и приборной доски устраивать крэш-тесты?

Мне не совсем понятно, как, в условиях недостатка времени, можно надеятся, что человек протестирует быстрее чем компьютер?

1. Когда я писал в VS 6.0 (на C++, понятно) я попытался сделать ЮТ: результат был поразительным: мой код был настолько отстойным, что отстойней просто некуда. Иногда создавалось такое впечатление, что я просто забыл, что и как хотел написать в коде. ЮТ просто выбили меня из задачи. После ещё нескольких попыток я понял, что ЮТ не для меня.
2. ЮТ как средство первичного тестирования неадекватно: они практически неспособны найти настоящие ошибки и часто выдают ложные. Для того, что бы нормально что-то проверить нужно извращаться. Следовательно, первичное тестирование должен делать человек-оператор.
3. Лично я (не призываю последовать за мной) всегда пишу программу так, что могу проверить все написанные мной элементы вручную, даже если работа над программой ещё далека от завершения.
4. Все мои программы содержат проверки на корректность полученного результата вычислений, даже если это заметно снижает производительность. Эти проверки нетривиальны (т.е. это не object.length != 0).
5. Как средство тестирования против разрушения существующего кода изменениями ЮТ являются адекватным средством автоматизации, но не оптимальным

Зачастую, проверить правильность исполнения кода может только человек. По крайней мере, надёжно проверить правильность. Фактически это означает, что ЮТ должны формироваться как запись некоторых действий человека-оператора с проверкой результата на соответствие сохранённому результату.
Проще говоря, это означает, что ЮТ должны быть вовсе не Ю, а КТ (комплексными тестами), которые формируются автоматически наподобие макросов в Excel, например. КТ должен хранить действия человека-оператора и результаты вычислений программы (естественно, только значимые части результатов), возможно, файлы конфигураций, save’ы и т.п.
Такие тесты могут формироваться, в том числе, и при нахождении ошибок оператором, не связанным напрямую с разработчиком (т.е. система формирования тестов может быть встроена в программу, а отчёт об ошибке в программе посылаться в виде соотв. неполного КТ). Что позволит в дальнейшем заранее предсказывать реакцию новой версии программы на действия этого пользователя.

Т.о. ЮТ не есть хорошо. Есть хорошо комплексное автоматизированное тестирование вариантов использования.


Оффтопик: где у Стругацких эта цитата?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

A>>>Если код не протестирован, то как можно говорить о том, что он работает правильно?
LCR>>Очень даже можно. Как я и говорил, убедиться в том, что он работает, можно наличием другого тестирования. Проверяются все варианты использования, какие нужны, а работа программы при -273'C не требуется. Предлагаешь вместо создания руля и приборной доски устраивать крэш-тесты?

ANS>Мне не совсем понятно, как, в условиях недостатка времени, можно надеятся, что человек протестирует быстрее чем компьютер?

Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем программист, который сделает хороший ЮТ

Здравствуйте, GlebZ, Вы писали:

LCR>>Тебе не трудно будет привести примерчик, что за параметры и что за xml. Хотя бы с высоты птичьего полёта?
GZ>Функции работали с эталонной базой данных. На выходе у них был результат в виде xml. Для проверки использовались эталонные xml в которых лежали xpath запросы и эталонные данные в том или ином виде(какие данные опциональные, какие-то должны быть в ответе обязательно и т.д.). И никаких моков.

Как то всё сложно. Вот с PostgresSQL идёт набор регресных тестов — там данные в текстовых файлах. Сравнивает один к одному результаты запросов с эталоном. Работает — как из пушки.

Или ты о чем то другом?

FDSC wrote:
> ANS>Мне не совсем понятно, как, в условиях недостатка времени, можно
> надеятся, что человек протестирует быстрее чем компьютер?
> Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем
> программист, который сделает хороший ЮТ
Если это GUI-приложение, то еще можно. А если приложение — это компилятор?

Здравствуйте, GlebZ, Вы писали:

GZ>3. В случае ассерт — мы можем тестировать только те пути, что выполняет тестер. А тестеры обычно не выполняют не все пути исполнения. Хорошо если они хотя бы выполнят функциональные тесты согласно требованиям. Иногда и даже этого не делают. Либо делают до того, как в проект были внесены ошибки.

Нужно снимать на камеру тестера и смотреть, как он работает

Здравствуйте, FDSC, Вы писали:

FDS>Т.о. ЮТ не есть хорошо. Есть хорошо комплексное автоматизированное тестирование вариантов использования.

Море воды и ни капли конструктива. Покажи пример такой системы о которой ты говоришь.

Здравствуйте, FDSC, Вы писали:

FDS>Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем программист, который сделает хороший ЮТ

Время? Скорость коммуникации между тестером и программистом на несколько порядков меньше скорости коммуникации программиста с собственным кодом.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, FDSC, Вы писали:

FDS>>Т.о. ЮТ не есть хорошо. Есть хорошо комплексное автоматизированное тестирование вариантов использования.

L>Море воды и ни капли конструктива. Покажи пример такой системы о которой ты говоришь.


Море конструктива. Я предлагают это делать и я кое-что из этого делаю. Если бы система уже была, я бы дал ссылку и не очем было бы говорить в философии.

Если вы считаете, что я написал воду, критикуйте эту воду. Так и пишите: это тривиально, то недоказано и т.п.

Здравствуйте, FDSC, Вы писали:

FDS>Море конструктива. Я предлагают это делать и я кое-что из этого делаю. Если бы система уже была, я бы дал ссылку и не очем было бы говорить в философии.
FDS>Если вы считаете, что я написал воду, критикуйте эту воду. Так и пишите: это тривиально, то недоказано и т.п.

Это прекрасный и безупречный сферический конь в вакууме. У тех, кто тестирует код стоит задача тестирования кода, а не написания инструмента для тестирования. Кажется это обсуждают в этой теме.

Здравствуйте, ekamaloff, Вы писали:

E>Тебе не кажется, что ты уводишь разговор в сторону? Ты привел пример неудачного использования ASSERT, тогда, когда нужно было использовать VERIFY, под видом того, что ASSERT — зло. Я обратил твое внимание на это.
Нет. Не должно было там использоваться VERIFY. Это совершенно разные функции. О чем я тебе и сообщил.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, FDSC, Вы писали:

FDS>>Море конструктива. Я предлагают это делать и я кое-что из этого делаю. Если бы система уже была, я бы дал ссылку и не очем было бы говорить в философии.
FDS>>Если вы считаете, что я написал воду, критикуйте эту воду. Так и пишите: это тривиально, то недоказано и т.п.

L>Это прекрасный и безупречный сферический конь в вакууме. У тех, кто тестирует код стоит задача тестирования кода, а не написания инструмента для тестирования. Кажется это обсуждают в этой теме.

А я не говорю, что они должны писать инструмент.Это то же самое, что сказать, что программист C++ должен написать компилятор C++ перед программированием. Мало того, я даже не говорю, что кто-то этот инструмент должен создавать. Я обхожусь без него, просто всё было сказано так, как по моему это было бы в идеале. И водяного тут не больше, чем у автора темы: и там, и там вс построено на личном опыте. Мало того, я предлагаю выход, а он просто говорит: вот ЮТ это хорошо, но они ничем помочь не могут.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>... о срочных проектах.
Тута есть еще одна штука. Если брать классические процессы, и это не система сделанная на коленке, то обычно действует правило 40-20-40, где 40 процентов времени занимет постановка, 20 программирование, и 40 процентов тестирование и отладка. Юнит-тесты могут сократить последнюю цифру.

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:
>> ANS>Мне не совсем понятно, как, в условиях недостатка времени, можно
>> надеятся, что человек протестирует быстрее чем компьютер?
>> Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем
>> программист, который сделает хороший ЮТ
C>Если это GUI-приложение, то еще можно. А если приложение — это компилятор?

Хм. И как его протестировать Unit тестами? Не смешите меня...

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, FDSC, Вы писали:

FDS>>Лекго и просто: тестировщиков побольше нанять, они стоят дешевле чем программист, который сделает хороший ЮТ

ANS>Время? Скорость коммуникации между тестером и программистом на несколько порядков меньше скорости коммуникации программиста с собственным кодом.

Смотря где. Тестерам не нужно коммуникаций: если есть ошибка идёт к программисту и говорит обо всём. Они должны работать бок о бок.
Всё равно ЮТ ничего не выявят на первых порах, именно когда сроки жмут.

Здравствуйте, FDSC, Вы писали:

FDS>Смотря где. Тестерам не нужно коммуникаций: если есть ошибка идёт к программисту и говорит обо всём. Они должны работать бок о бок.

Шутку понял. Смешно.

FDS>Всё равно ЮТ ничего не выявят на первых порах, именно когда сроки жмут.

А в конце сроки перестают жать? Привычка появляется?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Как то всё сложно. Вот с PostgresSQL идёт набор регресных тестов — там данные в текстовых файлах. Сравнивает один к одному результаты запросов с эталоном. Работает — как из пушки.

ANS>Или ты о чем то другом?
Почти. Тут тестируются не запросы БД как таковые, а функции. А полученный результат из БД может ими значительно трансформироваться на разных слоях системы.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>>Всё равно ЮТ ничего не выявят на первых порах, именно когда сроки жмут.

ANS>А в конце сроки перестают жать? Привычка появляется?

Нет, они разнашиваются. Я имею ввиду, что ЮТ не может найти ошибку, он может только показать, что ты испортил уже правильную оттестированную другими методами программу.
Ладно, вообще смысл есть, в том что я сказал, но в общем я не совсем прав