Os objetos de proxy são semelhantes às classes do wrapper quanto aos controles reais em teste. Qualquer comunicação da estrutura do Functional Tester com os controles AUT ocorre através desses objetos de proxy. Os objetos de proxy são criados e colocados onde o controle em teste pode ser acessado e consultado para informações. Um proxy é gravado como uma classe Java™ ou C#, que implementa a interface do Functional Tester prescrita para um objeto de teste de GUI em AUT. Quando seu aplicativo é ativado para teste, as classes de proxy são carregadas no aplicativo e se tornam parte dele. Um objeto de proxy se agrupa ao redor do objeto de teste de GUI real (o objeto nativo) em seu aplicativo, tornando-o passível de teste pelo Functional Tester.
A estrutura do Functional Tester suporta a criação de uma nova classe ProxyObject ou estende qualquer classe ProxyObject disponível para suportar testes de novos controles.
TestObjects são objetos de interface de script para o controle em teste. Um controle é exposto como TestObjects para o script de teste. Por exemplo, um controle de botão é exposto como GuiTestObject. Controles de nível superior como diálogos e quadros são expostos como TopLevelTestObject.
A execução de métodos de TestObject por vez ocorre através do ProxyObject correspondente. TestObjects residem no cliente Functional Tester. TestObjects têm referência ao ProxyObject, que por sua vez faz referência ao controle AUT em teste.
Para cada ambiente de teste que o Functional Tester suporta, como Java, HTML, .Net, Win32, Siebel e SAP, objetos de domínio são estabelecidos. Em cada domínio, há classes ProxyObject para todos os controles AUT suportados. As informações de mapeamento entre as classes ProxyObject e os controles AUT são armazenadas dentro de arquivos de customização no diretório de instalação do Functional Tester. Esses arquivos de customização atuam como um diretório para o Functional Tester, para saber qual ProxyObject é usado por qualquer controle AUT fornecido.
ProxyObjects também podem ser estendidos para criar novas classes ProxyObject para suportar controles de UI não-suportados. Por exemplo, para suportar o controle .Net 2.0 DataGridView, você pode criar uma nova classe de proxy Rational.Test.Ft.Domain.Net.DataGridViewProxy e inserir a entrada de mapeamento correspondente no arquivo rational_ft.rftcust. O seguinte código é um exemplo da seção atualizada no arquivo de customização.
<Obj L=".Proxy"> <ClassName>[WhidbeyControls]Rational.Test.Ft.Domain.Net.DataGridViewProxy</ClassName> <Replaces/> <UsedBy>[System.Windows.Forms]System.Windows.Forms.DataGridView</UsedBy> </Obj>