La riduzione del codice condizionale rende difficile valutare la copertura o il debug

4

Lavorando in Python, ho scritto alcune utility per affermare le pre-condizioni e re-interpretare le eccezioni, e ho scoperto che il mio codice non ha tanti rami.

Ho anche provato a spostare un'altra selezione del percorso del codice in mappe, quindi in base alle condizioni dei dati, verrà cercato un oggetto appropriato per eseguire le operazioni.

Il mio codice è principalmente una sequenza di istruzioni.

Ora ho difficoltà a collocare i punti di interruzione o a valutare la copertura del codice.

È normale quando ti sposti con uno stile più dichiarativo? (ovviamente sono ancora procedurale)

Ad esempio, invece di sollevare un'eccezione in alcune condizioni, trasmetto tutti questi dettagli a una funzione, insist .

Come sembrava prima:

if not condition:
    raise MyError('details {something} or {other}',
                  something=something,
                  other=other)
else:
    # rest of code

Come appare ora:

insist(condition, MyError, 
       'details {something} or {other}',
       something=something,
       other=other)

# rest of code

Ho anche qualcosa di simile per eliminare i blocchi di try/except quando so che voglio solo generare una nuova eccezione.

    
posta Peter Wood 09.09.2015 - 11:55
fonte

1 risposta

2

Avere meno filiali tecnicamente rende più facile raggiungere una copertura di filiali elevata, ma come sospetti, una copertura più alta non significa sempre che i test erano abbastanza buoni . All'estremo, puoi giocare tutti i tipi di trucchi per eliminare rami o renderli più facili da coprire, solo aumentare il punteggio non la qualità effettiva dei tuoi test. Anche altri criteri di copertura strutturale soffrono di questa limitazione, per quanto essi siano fantasiosi (anche il MCDC lo fa). Il modo in cui il codice è strutturato influisce sulla copertura e quindi influisce sull'efficacia della ricerca dei guasti ( link ).

Un rimedio a questo problema è quello di scrivere scrupolosamente gli oracoli o le asserzioni, insieme agli ingressi di test o al codice del driver. Intuitivamente, è più probabile che si rilevino errori se controlla di più , a parità di casi di test. Alcune metriche sono suggerite dagli accademici per misurare la copertura dell'oracolo, la copertura dei requisiti o la copertura controllata, ecc., Ma non esiste uno strumento pronto all'uso che io conosca.

    
risposta data 22.02.2017 - 03:48
fonte

Leggi altre domande sui tag