на самом деле, мой пример был самописка на коленке :(
Сейчас путем обходных умозаключений выяснилось, что XDE действительно берет CellRenderer при взятии данных из tablemodel с нестандартным cellrenderer. Сейчас попытаюсь взять-таки celleditor, который и есмь искомый комбобокс.

похоже, что максимум, что дозволено взять из ColumnModel -- названия и порядок столбцов. Мда-а-а-а-а

ситуация -- есть JTable, в котором хранятся, к примеру, JComboBox'ы. XDE Tester может промапить как GuiSubitemTestObject'ы собственно таблицу и заголовок. При попытке взять из модели значение, оказывается, что данные содержатся в виде String.
вопрос -- знает ли кто-нибудь способ достучаться именно до объекта Object, хранящегося в таблице? Пока есть только подозрение, плавно переходящее в уверенность, что в XDE не предусмотрена поддержка каких бы то ни было объектов в TableModel кроме String.

стоп-стоп-стоп

JFrame frame = new JFrame("test");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setSize(640, 480);
        JPanel panel = new JPanel();
        JTable table = new JTable(2, 1);
        table.setValueAt(new JComboBox(new Object[] {"one", "two"}), 0, 0);
        table.setValueAt(new JComboBox(new Object[] {"three", "four"}), 1, 0);

        JComboBox box = (JComboBox) table.getModel().getValueAt(0, 0);
        panel.add(box);
        frame.getContentPane().add(panel);
        frame.show();

Прекрасно достается все и приводится из модели.

IMHO, Acceptance Test -- любой тест, после корректного прохождения которого считается, что приложение обладает необходимым минимум корректно работающей функциональности. Размер этого минимума зависит от проекта\требований\проделанной работы. В таком случае не вижу причин, почему, например, скрипты RR-а или XDE Tester-а не могут служить Acceptance Test-ами. Поправьте, если я ошибаюсь.

У нас в результате действия может закрыться\не закрыться окно. Сaption у него может быть разный, но фиксировано начало(New Order:). Надо понять, закрылось оно все же или нет. По идее, кусок кода, приведенный ниже, должен работать, но, к сожалению, на практике дело обстоит иначе. Есть у кого-нибудь какие-нибудь мысли, как заставить заработать распознавание?

Result = SQAGetProperty ("Type=Window;CurrentFocus", "Caption", Value)
Select Case Value
Case "{New Order:*}"
Window SetContext, "Caption={New Order*}", ""
PushButton Click, "ObjectIndex=7"
Case Else
End Select

Window SetContext, "Caption={трам-пам-пам}", ""
Window CloseWin, "", ""

спасибо за советы.
На самом деле, если Case принимает только фиксированные значения, то понятно, почему не работало. Вопрос -- что такое "contains"? Оператора такого, у меня во всяком случае, нет.

Подскажите, кто знает, как запустить в Роботе приложение, зная в каком месте реестра можно посмотреть путь к нему?

а народ вообще с XDE Tester'ом работает?
Странно, что так мало ответов было..

вопрос решен.
Эта тема вообще интересна кому-нибудь, или отсутствие сообщений обусловлено незнанием ответа на вопрос?

спасибо за ответ.
Решения уже найдены (использование регулярных выражений оказалось вовсе не корявым решением; verification point-ы создаются программно, равно как и вывод информации в лог).

Добрый день.
Просьба помочь работавших(ющих) с XDE Tester'ом. Работаю с java-приложением, используется обфускация. Два вопроса не дают мне жить спокойно в связи с этим:
1. Распознавание объектов.
Т.к. используется обфускация, названия классов каждый раз разные. Как представляется, имеется два выхода:
а) имея логи обфускации, каждый раз перед началом, собственно, выполнения скрипта, менять значение всех свойств, в которых указывается класс в соответствии с логами;
Проблема: совсем непонятно, как менять программно recognition-свойства тестовых объектов;
B) не использовать свойство, определяющее имя класса;
Проблема: здесь беда в том, что у фрейма, добавленного в Test Object Map нельза ни грохнуть совсем свойство .class, ни присвоить ему нулевой вес (тоже, кстати, непонятно, где можно снять блокировку с изменения значения веса на этом свойстве);

Пока в качестве корявого выхода используется задание имени класса как регулярного выражения с пустым аргументом.

2. Добавление Verification Poit'ов
Есть ли како-либо способ добавлять их вручную, а не через визард? Визард не устраивает тем, что там нельзя (либо я не умею) редактировать recognition properties объекта. Из-за обфускации же значения там всегда будут разными.

Огромная просьба людям, имеющим знание об этих моментах, оставить здесь свои решения.

через gui смотреть путь в реестре, имхо, некрасиво.
Про то, как взять его (путь) с помощью стандартных функций, я не знал. Как это сделать -- именно в этом и заключался вопрос.

Господа, может ли кто подсказать, как решить следующую проблему: есть виртуальная машина (используется VMWare 4.5.2), надо загрузиться с сд-рома. Не удается. Пробовалось: менять virtual device node в опциях этой виртуальной машины -- Hard Disk ставить на IDE 0:1, CD-ROM ставить на IDE 0:0. Не помогает :( Буду признателен за любые предложения по тому, как же осуществить загрузку с сидюка.

Разобрался :)

Любой русский программист, после пары минут чтения кода, обязательно
вскочит и произнесет, обращаясь к себе: переписать это все нафиг. Потом
в нем шевельнется сомнение в том, сколько времени это займет, и остаток
дня русский программист потратит на то, что будет доказывать самому
себе, что это только кажется, что переписать это много работы. А если
взяться и посидеть немного, то все получится. Зато код будет красивый и
правильный. На следующее утро русский программист свеж, доволен собой и
без единой запинки докладывает начальству, что переписать этот кусок
займет один день, не больше. Да, не больше. Ну, в крайнем случае, два,
если учесть все риски. В итоге начальство даст ему неделю и через
полгода процесс будет успешно завершен. До той поры, пока этот код не
увидит другой русский программист.
А в это время, в соседних четырех кубиках, будет ни на секунду не
утихать работа китайских программистов, непостижимым образом
умудряющихся прийти раньше русского программиста, уйти позже, и при этом
сделать примерно втрое меньше. Эта четверка давно не пишет ничего
нового, а только поддерживает код, написанный в свое время индусом, и
дважды переписанный двумя разными русскими. В этом коде не просто живут
баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при
помощи любимой китайской технологии реиспользования кода - copy/paste.
Отсюда баги расползаются в разные стороны посредством статических
переменных и переменных, переданных по ссылке (ведь, китайский
программист не может смириться с неудобствами вызванными тем, что он не
может изменить значение внешнего параметра). Вспоминая об этих
переменных и ссылках, русский программист, как правило, на время теряет
дар английской речи, и переходит к какой-то помеси русского и
китайского. Он давно мечтает переписать весь кусок, над которым работают
китайцы, но у него нет времени. Он уже переписывает два больших куска, и
доказал начальству необходимость переписать третий. Кроме того, русский
программист боится обидеть китайцев. Они могут решить, что он пытается
вытеснить их с работы. К слову сказать, напрасно боится, поскольку
китайцы уже так решили.
На китайцах висят серьезные баги, о которых знает начальство и постоянно
их торопит. Китайцы уважают начальство и потому перевешивают баги друг
на друга очень торопливо. Они знают, что все попытки починить приведут к
появлению новых багов, еще худших. И в этом они правы. Разобраться в
том, в каком порядке меняются статические переменные, и как приобретают
свои значения, способен только один человек на фирме - индус. Но он
пребывает в медитации.
Поэтому, когда всю четверку уволят во время сокращения... А кого еще
увольнять? Русский - еще не переписал свой кусок, а индус - главная
ценность фирмы - он редко обращает внимание на проект, но когда
обращает, все понимают, что так как он, архитектуру никто не знает. Так
вот, когда китайцев увольняют, у их кода возможны две основные судьбы.
Первая - он попадет к русским, и его перепишут. Вторая - он попадет к
местному, канадскому программисту.
О, канадский программист это особый тип. Он, ни на минуту не
задумываясь, как рыцарь без страха и упрека, бросится фиксить самый
свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы
уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но
Баг каждый раз возвращался, как Бетмен в свой Готхем.
Итак, канадский программист, воспитанный на героической патетике
американского футбола - бросаться в бой головой вперед, сделает то, чего
китайцы не рисковали делать в течении трех долгих лет. Он, при помощи
дебагера, отследит место, где статическая переменная приняла значение -1
вместо правильного 0, и решительным движением заведет рядом вторую
переменную с правильным значением. Баг погибнет в неравной схватке с
героем. Но победа будет достигнута тяжелой ценой. Работать перестанет
все, включая только что переписанный русским программистом код. Это
повергнет русского программиста в задумчивость на целых два дня, после
чего он сделает, в общем-то, предсказуемый вывод о том, что дизайн с
самого начала был неправильным, и все надо переписать. На это нам нужна
неделя. Да, неделя, не больше.
Канадский программист смело бросится налаживать все, и станет еще хуже,
хотя казалось бы... Эта суета выведет из медитации индуса, который
придумает и вовсе гениальное решение - отбранчить код. Согласно его
плану, мы теперь будем поддерживать две версии одного и того же кода -
одну работающую, но с Багом, другую без Бага, но не работающую. Русский
программист, услышав об этом плане, сломает линейку об стол и обзовет
жену дурой, но на митинге возразить не решится.
К счастью, все это не сильно влияет на дела фирмы, поскольку продукт
продается и так. Поэтому менеджмент ходит в целом довольный и не устает
напоминать всем, что они отобраны как лучшие среди лучших. И что мы
давно доказали свою способность выпускать продукт тем, что выпускаем его
иногда.

(taken from from http://www.auto.ru/w...9/281276.shtml)

есть ли у кого сабж, или может кто достать?
В Питере найти не удается -- четвертую неделю везут.. :(
Послушать пример можно на http://www.yulanderson.com/.

пишем бридж, чтобы наша система умела работать по fix-протоколу.
Для тестирования, видимо, надо приобрести какой-либо fix-engine. Если у кого есть подобный опыт, посоветуйте, какой оптимальнее по соотношению цена-качество-удобство?

есть ли здесь люди, достаточно долго работающие\хорошо разобравшиеся с xde tester'ом?
Есть некие догадки по поводу его работы, но точной уверенности нет.
Пример: мне надо работать с базой данных. Было бы удобно описать в отдельном классе подключение к ней. Удобно делать также его через синглтон. Понятно, что при таком подходе тело мэйна этого класса остается пустым. При попытке откомпиллить выдается ошибка типа " Construct script class failed [MainConnection] [com.rational.test.ft.MethodNotFoundException: <init>]". Соотв-но это же выдается если пытаешься из скрипта получить коннекшн к базе, используя этот класс. Есть сильное подозрение, что в xde необходимо проходить функциональность, описанную в main'e. Кто-нибудь задавался подобными вопросами и\или имеет знание об ограничениях, присутствующих там?