È quello che vuoi una buona copertura? È improbabile che avere un test che esegua ogni ramo in un pezzo di codice significhi effettivamente che sia corretto, spesso si tratta più di casi angolari e in quanto sviluppatore si è nella posizione migliore per sapere quali sono questi casi angolari. Sembra anche che funzioni semplicemente dicendo 'ecco una combinazione di input interessante' considerando che molto probabilmente quello che vuoi è specificare il comportamento del sistema che vuoi vedere - se hai scritto il codice sbagliato in primo luogo allora l'interessante gli input possono essere completamente irrilevanti per il codice corretto.
Forse questa non è la risposta che stai cercando, ma direi che il modo migliore per farlo è a mano! Annota una specifica prima di iniziare la codifica e trasformala in un carico di casi di test quando sai/mentre stai scrivendo l'API per la tua classe/sottosistema.
Come iniziare la compilazione dell'API/scrivendo il codice è probabile che tu riceva pezzi e pezzi extra che devi fare + scoprire quali sono i bit difficili - se hai condizionali ecc. Che sono qualcosa che senti qualcuno che refactoring il tuo codice potrebbe sbagliare, quindi scrivi un test che li copra. A volte, in questi punti, scrivo intenzionalmente del codice errato, non riesco a eseguire un test e poi lo correggo solo per assicurarmi che il test stia verificando il percorso corretto attraverso il codice.
Poi cercare di pensare di tutti i valori dispari non si può avere coperte - input negativi, nulli ecc Spesso questi saranno i casi che non sono validi e non avete voglia di soddisfare/deve pensare - in questi casi lo farò Generalmente scriviamo alcuni test per dire che dovrebbero gettare delle eccezioni - che in pratica impediscono alle persone di usare il codice in modo errato nei casi in cui non si hanno informazioni adeguate/con dati non validi.
Hai menzionato sopra che stai lavorando con codice numericamente intensivo - potrebbe valere la pena di testare un livello superiore in modo da poter testare i comportamenti nel sistema che stai cercando piuttosto che il numero di crunch - presumendo che il codice non sia puramente numerico questo ti aiuterà a stabilire alcune condizioni reali di esecuzione e anche a garantire che qualsiasi cosa il bit di crunch numerico stia effettivamente interagendo con il resto del programma nel modo in cui ne hai bisogno - se è qualcosa di algoritmico probabilmente starai meglio scrivere un linguaggio di test di accettazione per aiutare a caratterizzare quali sono gli output desiderati in situazioni diverse - questo fornisce un quadro chiaro di ciò che stai cercando di ottenere, ti permette anche di lanciare grandi quantità di dati (reali) attraverso un sistema che è probabilmente migliore di un input generato dal computer. L'altro vantaggio è che se ti rendi conto che l'algoritmo ha bisogno di una drastica riscrittura per soddisfare qualche nuovo requisito, tutto ciò che devi fare è aggiungere il nuovo test case e quindi riscrivere/refactare; se i tuoi test fossero solo guardando i dettagli dell'algoritmo e assumendo gli effetti sul mondo esterno, avresti un grosso mal di testa cercando di capire come l'algoritmo al momento influenza il comportamento, quali parti erano corrette e quali no e poi provare a migrare un carico di test unitari su una nuova API/algoritmo.
fonte
2012-07-17 08:48:57
Evitare condizionali relativi a '==' per 'float's. Utilizzare invece '<' or '>'. Se devi usare '==', usa l'espressione 'Math.Abs (value - target)
@JesseChisholm Sono a conoscenza degli strumenti di analisi statica che consentono di trovare errori di codifica simili. Non sono sicuro di come questo aiuti con la domanda. – GregC
@GregC, non sono sicuro di aver capito cosa stai chiedendo. Volete sapere (A) se le istruzioni condizionali che contengono numeri in virgola mobile usano una tolleranza epsilon o (B) i vostri algoritmi sono numericamente stabili o (C) semplicemente una raccomandazione per uno strumento di copertura del codice? O qualcos'altro? –