Come si scrivono i test unitari quando è necessario che l'implementazione fornisca degli esempi?

In passato, ho scoperto che l'utilizzo di un'applicazione per fogli di calcolo come Excel per generare dati di test è stato molto utile per testare il codice matematico.

Scrivere lo stesso modello matematico due volte utilizzando due strumenti diversi (un linguaggio di programmazione e un foglio di calcolo) consente di individuare eventuali errori e garantisce che i dati di test generati siano indipendenti dal codice.

Ancora meglio - se puoi chiedere a qualcun altro di farlo per te, otterrai un paio di occhi in più sulla formula nel foglio di calcolo, e si assicurerà che i tuoi test siano completamente indipendenti.

Puoi anche usare Excel per assicurarti che i tuoi dati di test generati siano formattati in un modo che è davvero facile da copiare + incollare nei test delle tue unità.

Considerate anche input, eccezioni e codici di errore non validi. I tuoi test unitari servono a proteggere la gestione degli errori e la convalida di valori "impossibili" (compresi riferimenti null, ecc.).

Ci sono un paio di cose che potresti provare:

• Cerca di trovare alcuni valori di esempio che sono "ovviamente corretti" (nel senso che qualsiasi programmatore di manutenzione futuro può facilmente vedere che e perché sono corretti e verificare la loro correttezza nelle loro teste senza usare un calcolatore)
• Cerca la carta da cui deriva l'algoritmo e vedi se hanno degli esempi elencati qui, se sì, convertili in casi di test (e inserisci i riferimenti alla carta nel commento della documentazione del metodo di prova)
• Fornire "ovviamente corrette" le traduzioni 1: 1 dell'algoritmo dal documento in una o più lingue separate di altissimo livello (Matlab, Mathematica, Idris, Haskell, Julia, Python, ...) e scrivere uno script generare casi di test usando quelle implementazioni "ovviamente corrette". Lo script dovrebbe essere scritto in modo tale da poter facilmente verificare che i test test generati siano corretti.
• Cerca di trovare la traduzione 1: 1 più semplice e più vicina dell'algoritmo (o dell'equazione) nel tuo linguaggio di test, e usala per testare l'effettiva implementazione.

In quest'ultimo caso, potrebbe benissimo essere che l'implementazione nel caso di test e l'implementazione nel codice di produzione finiscono per essere identiche. Tuttavia, dovrebbe essere solo una coincidenza, non un obiettivo. Devi non copiare e incollare l'implementazione.

Ora, perché un tale caso di test, in cui il codice nel test e il codice nel codice di produzione sono identici, è utile? Bene, semplicemente: le modifiche al codice. I test di solito no.

Se esiste una cosa vera per qualsiasi parte di una pipeline grafica, allora è troppo lenta. Ora, probabilmente stai pensando: "il mio codice non è troppo lento!" E probabilmente hai ragione. Per il tuo caso d'uso. Per ora.

Ma credimi: a volte, da qualche parte, qualcuno avrà una pazza idea. Forse vogliono usare la tua libreria per l'elaborazione video in tempo reale in un impianto oculare alimentato dall'energia bioelettrica dell'occhio umano, e quindi con un budget di potenza seriamente limitato (e quindi un processore molto lento). Forse è un progetto artistico e vogliono rendere il video in tempo reale sull'intero muro cinese e quindi devono essere in grado di riprodurre trilioni di pixel a 60 Hz.

E poi dovrai ugolare il tuo algoritmo. Inserisci scorciatoie. Srotolare manualmente i loop. Scaricalo sulla GPU. Riscrivilo in assemblea. Forse anche implementarlo nell'hardware.

Tuttavia, il tuo test unitario sarà sempre lo stesso semplice, facilmente leggibile, facilmente comprensibile, codice di sicurezza, che funge da rete di sicurezza per tutte le cose pazze e brutte che devi fare al tuo codice di produzione, perché, beh, i vincoli reali avvengono.

In casi come questi, dove il test unitario sarebbe essenzialmente la duplicazione della funzione, mi sono chiesto spesso se dovessi scrivere i test unitari.

Quello che sono giunto alla conclusione è che a volte si , è prezioso.

Nella maggior parte dei casi non mi preoccuperei di fare un test, ma per qualsiasi parte critica di un sistema lo farei perché, sebbene il test stesso non sembri offrire molta utilità, ti avviserà comunque quando un altro sviluppatore accidentalmente interrompe la funzione.