2Евгений Барабашин.
То что вы просите называеться верефикацией программы. Насколько мне известно верефецированны АСУ парижского метро.
На самом деле количесво вриантов может быть при 10 полях, намного меньше .
Первый вариант, если поля независимы. ПРосто проверить каждое из полей, автономно 10 вариантов.
Если они зависимы то дерево вариантов сильно уменьшаеться за счет возможности НЕСУШЕСТВУЮЩИХ СОСТОЯНИЙ. Т.е. Если поле 1 ен введено то поля 2,..,10 немогут быть введены. Это какраз и уладываеться в возможность работы по бизнес правилам.
Возможный вариант из общего алгоритма выделять автономные куски и писать тесты для них.

Но верефикация щтука сложная. например если ты написал решение квадратного уравнения то проверяеш и 10-20 вариантов а не ((2^8)^10)Возможных параметров.

Просто уточнение:
Экстремальное программирование это целый набор взаимосвязанных методик, например регрессивное тесты никак не создаются для чего то уже сделаного. Тесты создаются первыми, а после реализации они становятся регрессивными. ;) К тому же _все_ варианты никогда и не тестируются. То есть для XP проблема в таком виде не стоит, но что делать если хочется протестировать?

Не знаю как для общего случая, но конкретный "простейшый пример" можно разобрать. Перебирать все случаи не надо, это точно. Необходимо выбрать _что_ надо протестировать. Считаем, что с логикой всё хорошо, она уже протестирована отдельно от GUI (если это сделать без GUI невозможно - лучше заняться рефакторингом, ещё одной методикой XP ;), чем тестированием).

Конечно, мы можем и не знать, что хочет изменить пользователь в документе, но наверняка знаем что он делает чаще всего. Таких случаев не должно быть много (на одну форму то!). Основной тест.

Целенаправленно искать "грабли", то есть тестировать только то в чём скорее всего может быть ошибка.

Monkey test (защита от дурака).

и т.д.

Только вот проверить "грабли" или провести monkey test достаточно на стадии отладки, вручную (то есть возможно их и придётся повторить, но вряд ли это будет часто, а тем более будет требовать автоматизации. А для регрессивного тестирования GUI как такового будет вполне достаточно основного теста.

То есть кажется мне что на форму должно приходится не более 1-2 автоматических тестов. Даже при всём богатстве вариантов.

>Евгений Барабашин

Это так, но тесты пишуться на основе того что даст заказчик и при непосредственном его участие. Помните про человека который отвечает на вопросы разработчиков и является сотрудником заказчика?
Правда возможно это уже адаптивная версия ХР.

Доброго дня.
Насколько я понимаю XP, тесты и unit-тесты програмист пишет для тестирования функциональности программы, то есть именно некоего вычислительного модуля, а не интерфейса.
Интерфейс в XP является величиной, зависящей от т.н. "дизайна" программы, который делается "максимально простым". Исходя из условия "простоты" получаем достаточно мелкое количество багов в GUI-интерфейсе, которые можетвыловить сам программист по мере работы или ближайший тестер.
Так или иначе, полягаю, что понятие "постоянного тестирования" относится именно к функциональности программы, а тестирование GUI в него не входит.

Возможно ХР имеет в виду в большей именно тесты исходников, движка программы.
Поэтому и существуют юнитесты.

Хотя разработка (дизайн) интерфейса тоже может быть при необходимости реформирована, доработана мозговым штурмом.

С другой стороны тест GUI можно провести,
дав попользовать его разным людям, записать для себя, как они думают при выборе контролов и работе с ними.

Я считаю, что программирование это творчество.
ХР скорей всего в этом случае сообщает нам правила, оперируя объектами разной природы. А уж способ реализации и то, как мы поймем эти правила - все зависит от нас.

> Alex Klyanchin

Изменение во View -> изменение значения свойства БО -> изменение View

Из за этой обратной связи на View  прогон тестов, которые меняют непосредственно свойства БО не гарантирует правильной работы программы.

> Путилин Евгений Валентинович
> Если смотреть Rational Robot, то он может делать проверку на дурака. Во все окна слать нажатия случайных клавиш и мыши.

Все таки 'умный дурак' работает не так.

> Второй вариант, пишеш скрит буквально работаеш спрограммо Robot запоминает что и как ты делал и пишет скрипт. Язык скрипта VBA или perl. Потом правиш скрипт например что бы в одну ячеку данные вносили последевательно 1,3,5,7,9,11,13,15,17,....

Это все детали. И проблема, как я сразу сказал в заглавии темы не в этом.

> AnoD
> Тестирование GUI с помощью XP преполагает, что у вас есть среда которая позволяет писать эти тесты, но не программисту, а заказчику.

Вроде в XP тесты пишет программист.

> All

Если мы зафиксируем сценарии работы: последовательность изменения свойств и пр., то мы конечно сможем просто автоматически тестировать. Но в результате получится, что пользователь должен сам четко помнить последовательность действий и если он от нее отклонится, могут быть любые ошибки, которые потом придется с трудом отлавливать.

Как бороться с огромным числом вариантов?

Можете рассмотреть, как вы будете тестировать пример, описанный в заголовке темы?

Если смотреть Rational Robot, то он может делать проверку на дурака. Во все окна слать нажатия случайных клавиш и мыши.
Второй вариант, пишеш скрит буквально работаеш спрограммо Robot запоминает что и как ты делал и пишет скрипт. Язык скрипта VBA или perl. Потом правиш скрипт например что бы в одну ячеку данные вносили последевательно 1,3,5,7,9,11,13,15,17,....
Таких систем много но они дорогие. Хотя Rational Sute можно получить 30 дневную версию
А что бы сажать человека надо действовать по такмоу плану. При написании программы пишется ТЗ, в котором описываюся требования к ней. Потом строися схема бизнес процессов, По ним и строится план тестирования. Который и прогняется каждй раз, при использовании Robot. Можно один раз прогнать человеком потом гонять машиной.
Каждый раз человек нужен только в исключительных случаеш это как правило дорогой и не надежый ресурс.
В Ratinal Unified Process есть сбор ошибок и запросов на изменение функциональности. Так там есть вариант робработка ишибка как не повторилась, среди Исправленна, Отложенна, Требование Расширения функциональности.
Вообщето есть несколько тем в котором затрагиваються проблеммы написани ПО, таких как постановка ТЗ, тестирование , и т.п. а Надо подходить способы написани ПО. И Варианты реализации кнкретных шагов.

>Все равно надо дизаблить некоторые поля в зависимости от ввода, >пересчитывать группу полей при изменении какого-то поля и пр. Или нет?

Наверное надо перейти на другой язык. Есть БО, есть его свойства. Одни свойства зависят от других. БО - это модель, форма - это отображение модели (MVC).

Есть конечно другие вещи которые требуется учитывать: это доступные из списка свойства, они тоже могут меняться динамически.

Самый лучший тестер GUI - человек.
Как мне кажется, тестирование в стиле XP это прежде всего тестирование алгоритмов и того как правильно они функционируют.
Тестирование GUI с помощью XP преполагает, что у вас есть среда которая позволяет писать эти тесты, но не программисту, а заказчику. И программист должен рассматривать эти тесты всего лишь как ТЗ. И как следствие, добиться срабатывания всех тестов, предполагает что вы всего лишь выполнилши то что хотел заказчик.

Давайте определимся: тестировать корректное поведение диалог. окон, чтобы ошибок не возникало, вводилсь только корректные данные и пр.

Юзабилити -- нечто другое и автоматически не тестируется. Для него надо сажать за программу пользователей и пр. -- это другой разговор.

> Alex Klyanchin

Все равно надо дизаблить некоторые поля в зависимости от ввода, пересчитывать группу полей при изменении какого-то поля и пр. Или нет?