Il codice procedurale di unit test è efficace?

In un progetto attuale, i poteri che vogliono avere unit test incorporati nel nostro ciclo di sviluppo per evitare la quantità costante di bug che sembrano penetrare nel nostro codice. Il problema è che il codice spaghetti è procedurale al 95%, con cui non ho mai effettuato test unitari (tutta la mia esperienza con i test unitari è stata con il codice OOP)

Quindi la mia domanda in breve è: sarebbe saggio procedere con i test unitari con la nostra base di codice attuale, o suggerirei che venga posticipato fino a quando l'applicazione non è stata migrata in un framework OOP adeguato?

PS: Mentre provavo a definire questa domanda come linguaggio agnostico, sento che affermare che l'applicazione in questione utilizza PHP e javascript aiuterà a fornire risposte più specifiche che potrebbero rispondere a questa domanda poiché dall'esperienza si verifica la maggior parte di queste applicazioni.

Il test unitario funziona bene con gli oggetti, soprattutto perché offre molte funzioni fantasiose, come gli oggetti finti, che aiutano a creare test migliori più velocemente.

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

Nota che dovrai:

• Isola 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 potranno mai accedervi direttamente. Probabilmente, nel tuo codice procedurale, alcune funzioni sono così e non necessitano di test.

• Pensa all'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 cose folli come cambiare $_GETo $_POSTarray all'interno funzioni.

• Gestire il codice con funzioni esterne. Questo è un caso più complicato, ma ancora possibile. O require_onceuna pagina per vedere cosa succede e catturare l'output tramite ob_start/ob_get_clean oppure eseguire una richiesta HTTP dalla suite di test e analizzare la risposta analizzando l'HTML. Questo non è in realtà un test dell'interfaccia utente: qui, non ti importa se un pulsante in una pagina appare a sinistra o a destra o se un link è in maiuscolo rosso o in blu. Quello che ti interessa è trovare alcuni elementi HTML tramite DOM e confrontare i loro contenuti con quello previsto.

• Prova i codici di risposta . require_oncecon l'output buffering è buono, ma devi anche testare come l'applicazione web gestisce gli errori. Ad esempio, se il risultato atteso di un test è 404 Not Found, è necessario eseguire una richiesta HTTP per sapere quale sia la risposta.

suggerire che sia rinviato fino a quando l'applicazione non è stata migrata in un framework OOP adeguato

Effettua alcuni test automatici prima di migrare su un'altra piattaforma, non in seguito. Aggiungi ulteriori test mentre esegui la migrazione, non in seguito. Se tali test sono "test di integrazione" o test unitari, devi decidere tu stesso, ma in genere puoi utilizzare il tuo framework di test xUnit preferito per entrambi i tipi.

Il modo più efficace per avviare i test unitari è identificare la classe di errori che si verificano più spesso o che rappresentano il costo più elevato. Quindi creare test mirati a quegli errori.

Il modo in cui questi test verranno implementati differirà tra paradigmi e lingue. Le cose più importanti che influenzeranno la tua capacità di eseguire test unitari è la qualità del codice; meno quindi il paradigma utilizzato. 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à più difficile il test.

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

Tutto ciò avrà un impatto maggiore sulla difficoltà dei test rispetto al paradigma del linguaggio.

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 è: il codice procedurale può essere efficacemente testato in unità, la domanda è: QUESTO codice può essere testato in unità. Ciò dipenderà dallo stato che legge e dallo stato che imposta. Idealmente la risposta ad entrambi è zero, ma se non lo è, puoi comunque testarla.

Come sempre, devi valutare la sicurezza che il codice sia corretto rispetto al costo per ottenere quella fiducia. Tenere presente che parte del guadagno per i test unitari è l'identificazione esplicita delle dipendenze e, in tal senso, è ancora più efficace testare il codice procedurale unitario rispetto al codice OOP.

Non penso che sia possibile effettuare test unitari reali contro il codice procedurale. Il problema principale è che ogni procedura avrà probabilmente molte dipendenze che non possono essere cancellate. Nella migliore delle ipotesi 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 utile, giusto?