Come scrivere test unitari per un'applicazione che esegue principalmente azioni "difficili da testare"? [duplicare]

0

Nella mia azienda sviluppiamo sistemi di acquisizione dati medici. Le principali funzioni di ogni applicazione sono:

  1. Interfaccia con hardware di campionamento dei dati;
  2. Salva / carica i dati raccolti su / da file sul disco;
  3. Eseguire analisi matematiche (DSP, elaborazione immagini) sui dati raccolti;
  4. Visualizza / calcola le informazioni utilizzando un'interfaccia utente grafica-pesante;

Per quanto ne so, queste sono esattamente le aree applicative che la maggior parte dei libri di testo sui test unitari consigliano di "non testare", o almeno che dovrebbe essere lasciata il più sottile possibile (tipicamente GUI) in modo da poter testare il " vera "funzionalità che è stata messa altrove (ad esempio, nei livelli del modello).

Sono sinceramente impegnato a elevare gli standard di qualità dei nostri progetti software, ma la natura delle nostre applicazioni e queste contro-indicazioni trovate su testi sull'argomento, mi fanno pensare se ciò è possibile, e se sì, come potrei aggirare queste limitazioni.

    
posta heltonbiker 17.11.2015 - 13:44
fonte

1 risposta

3

Prendi in giro le cose che non vuoi testare e scrivi test che esercitano solo la logica del business.

Ad esempio, non si desidera testare il codice di lettura / scrittura del file system. Questo è il lavoro dell'implementatore del file system. fai vuoi testare che il tuo codice trasforma i dati nel modo corretto. Pertanto, disaccoppiare il caricamento dei dati dall'elaborazione dei dati, iniettare un caricatore che importa i dati di test accuratamente elaborati e verificare che vengano trasformati nel modo previsto. Quello che stai descrivendo è precisamente il motivo per cui le persone raccomandano così tanto il principio di inversione delle dipendenze.

    
risposta data 17.11.2015 - 13:48
fonte

Leggi altre domande sui tag