Quando una pagina viene recuperata da WebTestCase tramite get() o post() il contenuto della pagina viene automaticamente analizzato. Il risultato è che ogni elemento contenuto dentro un tag <form> risulterà disponibile all'interno del test case. Per esempio, con questo snippet HTML: ]]> che avrebbe questo aspetto:

si potrebbe navigare il codice, sul sito LastCraft con il seguente test: function testDefaultValue() { $this->get('http://www.lastcraft.com/form_testing_documentation.php'); $this->assertField('a', 'A default'); } } ]]> Immediatamente dopo il caricamento della pagina, tutti gli elementi HTML vengono impostati al loro valore di default, proprio come nel caso apparissero nel browser. Gli assert dell'esempio si assicurano che nella pagina esista un widget HTML con il nome "a" e che il suo valore sia "A default".. Al solito, è possibile utilizzare un pattern invece di una stringa statica: get('http://www.lastcraft.com/form_testing_documentation.php'); $this->assertField('a', new PatternExpectation('/default/')); } } ]]> Si potrebbe eseguire il submit del form così com'è, ma prima si proverà a modificare il valore del campo di testo e solo allora si farà il submit: get('http://www.my-site.com/'); $this->assertField('a', 'A default'); $this->setField('a', 'New value'); $this->click('Go'); } } ]]> Siccome non è stato specificato un attributo method nel tag form e nemmeno una action, il test case seguirà l'usuale comportameto di un browser ed effettuerà il submit dei dati del form con una richiesta GET allo stesso indirizzo. In generale, piuttosto che cercare di individuare gli elementi mancanti in un form, SimpleTest cerca di emulare il più possibile il tipico comportamento di un browser. Il motivo di questo è che l'obiettivo di un framework di test è il collaudo della logica di un'applicazione PHP e non la valutazione della correttezza sintattica del codice HTML. Per gli errori HTML dovrebbero essere utilizzati altri tool come HTMLTidy o qualsiasi altro validatore HTML e CSS già sul mercato.

Se un campo non viene trovato in alcun form o se un'opzione non è disponibile, allora WebTestCase::setField() restituirà false. Per esempio, supponiamo che si voglia verificare che l'opzione "Superuser" non sia presente su questo form:

Select type of user to add:

    Subscriber
    Author
    Administrator

]]>

Il test seguente lo confermerebbe: $this->get('http://www.lastcraft.com/form_testing_documentation.php'); $this->assertFalse($this->setField('type', 'Superuser')); } } ]]> Se il nuovo valore non è una delle opzioni, la selezione corrente non viene modificata.

Di seguito un elenco di tutti i widget correntemente supportati:

• Campi di testo, compresi i campi nascosti e le password.
• Pulsanti di submit, compreso il tag button ma escluso il pulsante reset
• Text area. E' compreso anche il comportamento "A capo automatico"
• Checkboxe, compresi i checkboxe multipli all'interno dello stesso form
• Elenchi a cascata, inclusi quelli con selezione multipla
• Radio buttons
• Immagini

L'emulazione del browser offerta da Simpletest imita le azioni che un utente può effettuare su una pagina HTML standard. Javascript non è supportato ed è improbabile che venga aggiunto il supporto a breve.

Un aspetto da tenere in considerazione è che la tecnica Javascript di inviare i form dopo l'impostazione di un campo nascosto non può essere emulata con i normali comandi di SimplTest. Si veda oltre per un sistema di collaudo di form di questo tipo.

SimpleTest può gestire due tipi di controlli multivalore: i drop-down multipli e i checkbox multipli all'interno dello stesso form. La natura di questi elementi comporta che la loro impostazione ed il loro collaudo debba essere eseguito in modo leggermente differente. Vediamo un esempio con i checkbox:

    Create privileges allowed:
    

    Retrieve privileges allowed:
    

    Update privileges allowed:
    

    Destroy privileges allowed:
    

    

]]>

Se si desidera disabilitare tutti i checkbox escluso "Retrieve privileges allowed" ed eseguire poi il submit, si può fare così: function testDisableNastyPrivileges() { $this->get('http://www.lastcraft.com/form_testing_documentation.php'); $this->assertField('crud', array('c', 'r', 'u', 'd')); $this->setField('crud', array('r')); $this->click('Enable Privileges'); } } ]]> Piuttosto che impostare il campo con un singolo valore, si è fornito un elenco di valori. Si fa la stessa cosa quando si verificano i valori attesi. Si può procedere quindi scrivendo altri test per confermare l'effetto di quest'ultimo, per esempio eseguendo il login con l'utente selezionato e tentando di fare un update.

Se si vuole collaudare un form che fa affidamento sul fatto che Javascript imposti un campo nascosto, non sarà sufficiente invocare setField(). Il codice riportato qui di seguito non funzionerà: // This does *not* work $this->setField('a_hidden_field', '123'); $this->clickSubmit('OK'); } } ]]> Piuttosto, ci sarà bisogno di passare dei parametri aggiuntivi al metodo clickSubmit(): $this->clickSubmit('OK', array('a_hidden_field'=>'123')); } } ]]> Si tenga in mente che in questo modo si sta effettivamente cortocircuitando una parte del proprio software (il codice javascript nel form) e forse sarebbe meglio utilizzare strumenti come Selenium per assicurare un collaudo più completo.

Se si vuole collaudare un gestore di form non non si è ancora scritto il form o non vi si può accedere, è possibile invocare il submit manualmente: function testAttemptedHack() { $this->post( 'http://www.my-site.com/add_user.php', array('type' => 'superuser')); $this->assertNoText('user created'); } } ]]> Aggiungendo WebTestCase::post() si sta emulando il submit del form. Normalmente si userà questo sistema come espediente provvisorio o nel caso ci si aspetti che sia un componente di terze parti ad eseguire il submit. Un'eccezione a questo è quando si desidera collaudare la protezione dai tentativi di spoofing delle pagine.