Come generare una buona copertura del codice della logica a virgola mobile?

Question

Sono un nuovo codice per la lavorazione a mano. Mi piacerebbe assicurarmi di non lasciare nulla di intentato.

C'è qualcosa di specifico che posso fare oltre a specificare i Contratti di codice per guidare Pex in modo che produca una buona copertura in codice numericamente intensivo?

Provare a cercare http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdf per la parola chiave "float" per alcune informazioni di background.

vincoli aritmetici oltre numeri in virgola mobile sono approssimati da una traduzione di numeri razionali, e le tecniche di ricerca euristici sono utilizzati al di fuori della Z3 di trovare soluzioni approssimate per floating point vincoli.

... e anche ...

ragionamento simbolico. Pex utilizza un risolutore di vincoli automatico per determinare quali valori sono rilevanti per il test e il codice sotto test. Tuttavia, le abilità del risolutore di vincoli sono, e saranno sempre, limitate. In particolare, Z3 non può ragionare con precisione sull'aritmetica in virgola mobile.

In alternativa, si conosce uno strumento in .NET che è più adatto per il compito di trovare anomalie numeriche sotto .NET? Sono a conoscenza di http://fscheck.codeplex.com/ ma non esegue il ragionamento simbolico.

Answer 1

È 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.