Il codice procedurale di test unitario è efficace?

Il test delle unità funziona bene con gli oggetti, soprattutto perché offre molte funzioni di fantasia, come oggetti finti, che aiutano a creare test migliori più velocemente.

Detto questo, nulla vieta di fare test unitari su una base di codice procedurale . In OOP, la maggior parte dei test unitari sta testando i metodi passando ad alcuni parametri e aspettandosi un risultato o un'eccezione di un tipo specifico. Questo può essere fatto anche con il codice procedurale; solo che invece di testare i metodi, testerai le funzioni .

Nota che dovrai:

• Isolare le funzioni che devi testare e quelle che non ti servono. In OOP, questo è facile: i metodi privati non devono essere testati perché i chiamanti non saranno mai in grado di accedervi direttamente. Le probabilità sono, nel tuo codice procedurale, alcune funzioni sono così e non hanno bisogno di test.

• Pensa a ambito globale . Il problema esiste anche in OOP, ma se dici che devi testare il codice spaghetti, è probabile che le persone che hanno scritto questo codice abbiano cattive abitudini, come usare troppo l'ambito globale e fare alcune cose pazzesche come cambiare $_GET o $_POST matrici all'interno delle funzioni.

• Gestire il codice al di fuori delle funzioni. Questo è un caso più complicato, ma ancora possibile. O tu require_once una pagina per vedere cosa succede e cattura l'output attraverso ob_start / ob_get_clean , oppure fai una richiesta HTTP dalla suite di test e analizza la risposta analizzando l'HTML. Questo non è davvero un test dell'interfaccia utente: qui, non ti interessa se un pulsante su una pagina appare a sinistra o a destra o se un link è in caratteri maiuscoli rossi grandi o in piccoli caratteri blu. Ciò che ti interessa è trovare alcuni elementi HTML tramite DOM e confrontare il loro contenuto con quello previsto.

• Prova i codici di risposta . require_once con il buffering dell'output è buono, ma devi anche testare come l'applicazione web gestisce gli errori. Ad esempio, se il risultato previsto di un test è 404 non trovato, è necessario eseguire una richiesta HTTP per sapere qual è la risposta.

suggest that it be postponed until the application has been migrated to a proper OOP framework

Ottieni alcuni test automatici in prima prima di migrare a un'altra piattaforma, non dopo. Aggiungi ulteriori test durante la migrazione, non dopo. Se quei test sono "test di integrazione" o test unitari devi decidere da solo, ma in genere puoi usare il tuo framework di test xUnit preferito per entrambi i tipi.

Ogni volta che si verifica una situazione in cui è possibile testare automaticamente parti del codice, il test dell'unità può essere efficace. Quindi, la domanda non è che il codice procedurale possa essere efficacemente testato, la domanda è che questo codice possa essere testato unitamente. Ciò dipenderà da quanto stato legge e da quanto stabilito. Idealmente la risposta a entrambi è zero, ma se non lo è, puoi comunque testarlo.

Come sempre è necessario valutare la sicurezza che il codice sia corretto rispetto al costo di ottenere quella confidenza. Tieni presente che parte del guadagno per i test unitari sta identificando esplicitamente le dipendenze, e in questo senso è ancora più efficace per testare il codice procedurale unitario rispetto al codice OOP.

Il modo più efficace per avviare il test dell'unità è identificare la classe di errori che si verificano più spesso o il costo più alto. Quindi crea test mirati a tali errori.

Il modo in cui tali test vengono implementati differirà tra paradigmi e linguaggi. Le cose più importanti che avranno un impatto sulla tua capacità di eseguire test unitari sono la qualità del codice; meno così il paradigma usato. Ricorda che il test unitario riguarda il test di una "unità" di codice in isolamento. Tutto ciò che influisce sulla tua capacità di isolare "unità" di codice renderà i test più difficili.

• uso di globals
• effetti collaterali
• codice strettamente accoppiato
• codice mal collegato
• un gran numero di condizionali
• "unità" mal progettate

Tutti questi avranno un impatto maggiore sulla difficoltà di test rispetto al paradigma linguistico.

Non penso sia possibile fare veri test unitari contro il codice procedurale. Il problema principale è che ogni procedura avrà probabilmente molte dipendenze che non possono essere eliminate. Al meglio i test saranno test di integrazione. Ho fatto una cosa simile molte lune fa con moduli VB6 e moduli VBA in MS Access.

Detto questo, se riesci a mettere il ponteggio di prova attorno ai metodi che causano più dolore, questo deve essere di valore, giusto?