Test unitario: programmazione strutturata vs non strutturata [chiusa]

No. A meno che non si voglia distorcere seriamente il significato del termine "unit test" in modo tale che esso diventi essenzialmente sinonimo di "test di sistema", l'unità che testa un sistema che non ha unità individuali da testare non ha senso.

Ovviamente puoi fare test di sistema. Se il codice esegue più funzionalità, è possibile eseguire test funzionali. Se il codice si integra con un altro codice, puoi eseguire test di integrazione. Se si dispone di alcuni criteri di accettazione per il codice, è possibile eseguire test di accettazione. Puoi eseguire test delle prestazioni.

Ma non puoi fare il test unitario, perché i test unitari testano le singole unità indipendenti in isolamento, e non ci sono singole unità indipendenti nel codice non strutturato (questo è praticamente ciò che significa "non strutturato").

In pratica stai parlando di un'unità molto grande. Normalmente, scriveresti molti piccoli test di unità per unità di piccole dimensioni, ma in questo caso sarà probabilmente un sacco di test elaborati per una grande unità.

Al mio lavoro, abbiamo lo stesso tipo di problema. In alcuni dei nostri prodotti utilizziamo SOUP (Software di provenienza sconosciuta), che dobbiamo "unit test" per conformarci a regole e regolamenti relativi ai nostri prodotti.

SOUP può essere una libreria, ad es. uno stack Bluetooth o un framework di esecuzione, ad es. QP / C . Scriviamo test che eseguono l'API o scrivono applicazioni di test che integrano il SOUP e testano le sue funzioni (interne).

Una funzione importante di questi test è quella di rilevare la regressione o le modifiche indesiderate quando il SOUP viene aggiornato. Ma la maggior parte delle volte, questi test sono usati per verificare che il SOUP faccia quello che ci si aspetta che faccia e che non ci siano brutte sorprese o casi d'angolo.

Sviluppare test di "unità" per un pezzo di software non strutturato è anche molto utile se si desidera ristrutturarlo o sostituirlo.