Le funzioni di test unitario con effetti collaterali?

Question

Supponiamo che stiate scrivendo una funzione per verificare se una pagina è stata raggiunta dall'URL appropriato. La pagina ha uno stub "canonico" - ad esempio, mentre una pagina può essere raggiunta su stackoverflow.com/questions/123, preferiremmo (per ragioni SEO) reindirizzare a stackoverflow.com/questions/123/how-do -i-move-the-turtle-in-logo - e il reindirizzamento effettivo è contenuto in modo sicuro nel suo metodo (ad esempio redirectPage ($ url)), ma come testare correttamente la funzione che lo chiama?

Per esempio, prendete la seguente funzione:

function checkStub($questionId, $baseUrl, $stub) { 
    canonicalStub = model->getStub($questionId); 
    if ($stub != $canonicalStub) { 
    redirectPage($baseUrl . $canonicalStub); 
    } 
} 

Se si dovesse unit test la funzione checkStub(), non sarebbe il reindirizzamento ottenere nel modo?

Questo fa parte di un problema più ampio in cui alcune funzioni sembrano diventare troppo grandi e lasciano il regno dei test delle unità e nel mondo dei test di integrazione. La mia mente pensa immediatamente a router e controller come ad avere questo tipo di problemi, in quanto testarli porta necessariamente alla generazione di pagine piuttosto che essere limitati solo alla propria funzione.

Ho appena fallito al test unitario?

Answer 1

Sembra che tu abbia appena un altro test case. È necessario verificare che lo stub sia identificato correttamente come uno stub con test sia positivi che negativi e che sia necessario verificare che la pagina verso cui si viene reindirizzati sia corretta.

Oppure ho totalmente frainteso la domanda?

Answer 2

Tu dici ...

Questo fa parte di un problema più ampio in cui alcune funzioni sembrano ottenere troppo grande e lasciare il regno di unit testing e nel mondo dei test di integrazione

Penso che questo sia il motivo per cui il test unitario è (1) difficile e (2) porta al codice che non si sgretola sotto il suo stesso peso. Devi essere meticoloso per rompere tutte le tue dipendenze o finire con test unitari == test di integrazione.

Nell'esempio si inserisce un redirector come dipendenza. Usi un finto, doppio o spia. Quindi esegui i test mentre @atk si espande. A volte non ne vale la pena. Più spesso ti costringe a scrivere codice migliore. Ed è difficile fare a meno di un container IOC.

Answer 3

Questa è una vecchia domanda, ma penso che questa risposta sia pertinente. @Rob afferma che si dovrebbe iniettare un redirector come dipendenza - e sicuramente, questo funziona. Tuttavia, il tuo problema è che non hai una buona separazione delle preoccupazioni.

È necessario rendere le proprie funzioni quanto più possibile atomiche e quindi comporre funzionalità più grandi utilizzando le funzioni granulari che sono state create. È stato scritto da:

function checkStub($questionId, $baseUrl, $stub) { 
    canonicalStub = model->getStub($questionId); 
    if ($stub != $canonicalStub) { 
    redirectPage($baseUrl . $canonicalStub); 
    } 
} 

mi piacerebbe scrivere questo:

function checkStubEquality($stub1, $stub2) { 
    return $stub1 == $stub2; 
    } 

    canonicalStub = model->getStub($questionId); 
    if (!checkStubEquality(canonicalStub, $stub)) redirectPage($baseUrl . $canonicalStub);