Gli oggetti proxy sono simili alle classi wrapper per i controlli reali sottoposti a test. Eventuali comunicazioni del framework Functional Tester con i controlli AUT avviene mediante questi oggetti proxy. Gli oggetti proxy vengono creati e inseriti nel punto in cui è possibile accedere al controllo sottoposto a test ed eseguire query per informazioni. Un proxy è scritto come una classe Java™ o C#, che implementa l'interfaccia Functional Tester prescritta per un oggetto di test GUI nell'AUT. Quando l'applicazione in uso è abilitata per l'esecuzione di test, le classi proxy vengono caricate nell'applicazione e diventano parte di essa. Un oggetto proxy ricopre l'oggetto di test GUI corrente (l'oggetto nativo) nell'applicazione in uso, rendendone possibile l'esecuzione del test da Functional Tester.
Il framework Functional Tester supporta la creazione di una nuova classe ProxyObject o l'estensione di una classe ProxyObject disponibile a supportare l'esecuzione di test di nuovi controlli.
I TestObject sono gli oggetti di interfaccia script per il controllo sottoposto a test. Un controllo è esposto come un TestObject allo script di test. Ad esempio, un controllo pulsante è esposto come GuiTestObject. Controlli di livello superiore come finestre di dialogo e frame vengono esposti come TopLevelTestObject.
L'esecuzione dei metodi TestObject avviene a turno mediante il corrispondente ProxyObject. I TestObject risiedono nel client Functional Tester. I TestObject hanno un riferimento al ProxyObject che a turno fa riferimento al controllo AUT sottoposto a test.
Per ogni ambiente di esecuzione di test supportato da Functional Tester, come Java, HTML, .Net, Win32, Siebel e SAP, vengono stabiliti degli oggetti di dominio. In ogni dominio ci sono classi ProxyObject per tutti i controlli AUT supportati. Le informazioni di associazione tra le classi ProxyObject e i controlli AUT vengono memorizzati all'interno dei file di personalizzazione nella directory di installazione Functional Tester. Tali file di personalizzazione operano come una directory per Functional Tester per sapere quale ProxyObject è utilizzato per un dato controllo AUT.
È possibile anche estendere ProxyObject per creare nuove classi ProxyObject per supportare controlli UI non supportati. Ad esempio, per supportare il controllo .Net 2.0 DataGridView, è possibile creare una nuova classe proxy Rational.Test.Ft.Domain.Net.DataGridViewProxy e inserire la voce di associazione corrispondente nel file rational_ft.rftcust. Il codice riportato di seguito è un esempio della sezione aggiornata nel file di personalizzazione.
<Obj L=".Proxy"> <ClassName>[WhidbeyControls]Rational.Test.Ft.Domain.Net.DataGridViewProxy</ClassName> <Replaces/> <UsedBy>[System.Windows.Forms]System.Windows.Forms.DataGridView</UsedBy> </Obj>