Создание пользовательского элемента управления более тестируемым в TestComplete

Question

(Это может быть лучше на форумах TestComplete, но я все равно решил попробовать здесь)

Мы смотрим на автоматизированное тестирование нашего Delphi 2010 приложенияс TestComplete .Основным элементом управления, используемым нашим приложением, является наш собственный пользовательский элемент управления, который напрямую получен из TCustomControl .

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

Мы являемсячтобы сделать его более дружественным к TestComplete, чтобы мы могли считывать из него данные (например, какие данные загружаются в элемент управления, какие данные выбраны)

Я должен также упомянуть, что наше приложение используетАрхитектура MVC и интенсивно использует интерфейсы.Агент отладки TestCompletes не может возвращать какую-либо информацию о типах интерфейсов, и поэтому мы не можем получить от них никаких данных.Я подозреваю, что это корень нашей проблемы

Я рассматриваю эти два подхода:

1. Добавьте новые свойства в элемент управления, который будет возвращать информацию ов настоящий момент выбрано поле (а).например, текст в поле, положение на экране, иерархический путь и доступ к ним через агент отладки TestCompletes.

2. Посмотрите на создание дополнения пользовательского элемента управления для TestComplete (я даже не уверенВы можете сделать это с помощью элементов управления Delphi)

Проблема с первым подходом заключается в том, что компоновщик часто выявляет свойства и функции, если они не используются.Мы хотим использовать нашу сборку релиза для тестирования, а не для отладочной сборки.

У кого-нибудь есть какие-либо советы по этому поводу или опыт работы с подобными вещами?

Спасибо

Редактировать:Я только что прочитал справку по SDK, а дополнения для пользовательских элементов управления можно создавать только для элементов управления .net и WPF.

Answer 1

Вы правы насчет отладочной информации - вы можете удалить ее из сборки выпуска.Таким образом, вы протестируете сборку релиза и получите доступ к внутренним компонентам одновременно.Примечание относительно этой ситуации: «компоновщик часто определяет свойства и функции, если они не используются».Вы можете обмануть здесь, чтобы компоновщик генерировал отладочную информацию для этих функций:

1. Сделать опубликованные функцииКомпоновщик не касается опубликованных элементов.
2. Сделайте функции виртуальными.Компоновщик не исключает виртуальные методы.
3. Вызывайте ваши функции где-нибудь в вашем коде.Чтобы включить вызов в свой код, не вызывая ничего, вы можете сделать что-то вроде этого:

var t: Boolean;
begin
  t := False;
  if  t = True then
    TheFunctionThatNeverExecutes();
...
end;

Answer 2

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

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

Создайте небольшую (возможно, невидимую) тестовую форму, где вы централизуете доступ к экземплярам этих классов.(Теперь ссылка на режим выпуска). Создавайте эту форму только в режиме отладки, поэтому при тщательном проектировании вы можете ссылаться на соответствующий код только тогда, когда это необходимо для тестирования.