Scrittura software senza test di unità

2

Di solito, quando scrivo software, uso test di unità per ciascuna funzione per verificare se funziona senza problemi. Tuttavia, recentemente mi sono ritrovato a scrivere alcuni software che non sono davvero suscettibili di test unitari. Ad esempio, scrivere il codice per un sistema operativo, in cui le librerie standard non sono disponibili. Un altro esempio è la scrittura dei vincoli di un problema di programmazione lineare intera, in cui nessuna soluzione può essere vista fino a quando non sono stati aggiunti tutti i vincoli. In questi casi, ho faticato a eseguire il debug del mio codice, poiché identificare quale parte del codice causa problemi è stata molto difficile. Qualche suggerimento su come trattare questi casi?

Aggiornamento: volevo scrivere la funzionalità di mappatura di pagina di un sistema operativo. Il sistema utilizzava il paging a 4 livelli. Il mio codice utilizzava una funzione per passare da un livello di tabella di pagine a quello successivo. Sebbene sapessi che l'algoritmo era corretto, il sistema non funzionava come previsto. Tuttavia, non sono stato in grado di scoprire quale funzione stava creando il problema, poiché era impossibile conoscere l'esatto output corretto di ciascuna funzione. Invece, ho dovuto fare una serie infinita di prove ed errori (qualcosa che mi ha richiesto più di una settimana) per scoprire il problema.

Grazie.

    
posta Arani 01.10.2014 - 19:15
fonte

1 risposta

4

Il test dipendente dall'hardware può essere difficile da testare, anzi, finché non si ha a disposizione un simulatore affidabile. Il codice OS / kernel dipendente può essere testato tramite unità fornendo un'interfaccia astratta al sistema operativo o alle funzioni del kernel che consente di simulare queste funzioni. Naturalmente, quando le funzioni del sistema operativo non si comportano come ci si aspetta che si comportino, è possibile fornire test unitari per queste funzioni , una dopo l'altra, per scoprire come funzionano davvero.

Ma il codice per risolvere un problema di "Programmazione lineare intera" è in genere ben controllabile:

  • il risolutore ILP può essere testato unitamente utilizzando molti piccoli problemi con pochi vincoli
  • ciascuno dei vincoli è tipicamente una piccola funzione autonoma booleana, che è perfetta per i test unitari

Infatti, se vuoi testare se hai implementato i vincoli right e l'unico modo per verificarlo è eseguire il tuo risolutore ILP black-box con un vettore di vincoli di dimensioni > 10000 , quindi potresti avere un problema con i tuoi test di integrazione , non con i tuoi test di unità. Ma per gli spazi con problemi di questo tipo, i vincoli sono tipicamente parametrici e il numero di vincoli è in genere un parametro, che offre la possibilità di testarlo con "n constraints" prima dove n viene scelto un numero molto piccolo.

    
risposta data 01.10.2014 - 19:48
fonte

Leggi altre domande sui tag