È possibile testare l'unità PHP procedurale, nessun problema. E non sei assolutamente sfortunato se il tuo codice è mescolato con HTML.
A livello di test di accettazione o applicazione, il PHP procedurale probabilmente dipende dal valore dei superglobali ($_POST, $_GET, $_COOKIE
, ecc.) Per determinare il comportamento e termina includendo un file modello e sputando l'output.
Per eseguire test a livello di applicazione, è sufficiente impostare i valori superglobali; avvia un buffer di output (per mantenere un po 'di html dall'inondazione dello schermo); chiama la pagina; asserire contro cose all'interno del buffer; e cestino il buffer alla fine. Quindi, si potrebbe fare qualcosa di simile:
public function setUp()
{
if (isset($_POST['foo'])) {
unset($_POST['foo']);
}
}
public function testSomeKindOfAcceptanceTest()
{
$_POST['foo'] = 'bar';
ob_start();
include('fileToTest.php');
$output = ob_get_flush();
$this->assertContains($someExpectedString, $output);
}
Anche per enormi "quadri" con un sacco di comprende, questo tipo di test vi dirà se si dispone di funzionalità a livello di applicazione di lavoro o meno. Questo sarà molto importante quando inizierai a migliorare il tuo codice, perché anche se sei convinto che il connettore del database funzioni ancora e abbia un aspetto migliore di prima, dovrai fare clic su un pulsante e vedere che, sì, puoi ancora accedere e uscire tramite il database.
A livelli inferiori, esistono variazioni minori a seconda dell'ambito della variabile e se le funzioni funzionano in base agli effetti collaterali (restituendo true o false) o restituiscono direttamente il risultato.
Le variabili passano esplicitamente, come parametri o matrici di parametri tra le funzioni? O le variabili sono impostate in molti posti diversi e passate implicitamente come globali? Se è il caso (buono) esplicito, è possibile testare una funzione unitaria (1) includendo il file contenente la funzione, quindi (2) inserire direttamente i valori del test funzionale e (3) catturare l'output e asserirlo contro di esso. Se stai usando globals, devi solo fare attenzione (come sopra, nell'esempio $ _POST) per eliminare con attenzione tutti i globals tra i test. È anche particolarmente utile mantenere i test molto piccoli (5-10 linee, 1-2 asserzioni) quando si ha a che fare con una funzione che spinge e tira un sacco di globals.
Un altro problema di base è se le funzioni funzionano restituendo l'output o modificando i parametri passati, restituendo true/false. Nel primo caso, il test è più facile, ma ancora una volta, è possibile in entrambi i casi:
// assuming you required the file of interest at the top of the test file
public function testShouldConcatenateTwoStringsAndReturnResult()
{
$stringOne = 'foo';
$stringTwo = 'bar';
$expectedOutput = 'foobar';
$output = myCustomCatFunction($stringOne, $stringTwo);
$this->assertEquals($expectedOutput, $output);
}
Nel caso in male, in cui il codice funziona da effetti collaterali e restituisce vero o falso, è ancora possibile testare abbastanza facilmente :
/* suppose your cat function stupidly
* overwrites the first parameter
* with the result of concatenation,
* as an admittedly contrived example
*/
public function testShouldConcatenateTwoStringsAndReturnTrue()
{
$stringOne = 'foo';
$stringTwo = 'bar';
$expectedOutput = 'foobar';
$output = myCustomCatFunction($stringOne, $stringTwo);
$this->assertTrue($output);
$this->Equals($expectedOutput, $stringOne);
}
Spero che questo aiuti.
Questo non è corretto se il codice che si sta testando è pieno di istruzioni 'exit;' :( –
@YarekT Nessun test può andare bene se il codice è pieno di istruzioni 'exit' o' die'. Il modo più verificabile per Gestire la terminazione prevista dello script è generando un'eccezione e registrando un gestore di eccezioni personalizzato che sia abbastanza intelligente da ignorare il tipo di eccezione personalizzato quando viene rilevato, quindi è possibile verificare che l'eccezione prevista venga generata. Ho mai avuto bisogno di 'exit' o' die' dopo la fase di bootstrap comunque. – rdlowrey