Analisi del codice statico in grado di identificare tutti i percorsi linearmente indipendenti e scoprire casi limite. Una volta identificati, i test unitari possono essere creati da quell'analisi per esercitare tutti i percorsi indipendenti e i casi limite. Questo è essenzialmente test della casella bianca. I test delle unità possono essere scritti manualmente oppure possono essere generati dal codice.
È molto probabile che tale analisi avvenga, non a livello di codice sorgente, ma probabilmente a livello di AST (abstract syntax tree) nel compilatore, o al livello di byte-code / livello intermedio (dove adeguato esistono metadati per supportare l'analisi).
Quando sento la frase "se questo può essere usato a un livello superiore, ad esempio il flusso generale di un'applicazione", penso ai test di integrazione, non ai test unitari.
Il modo in cui i componenti della tua applicazione integrare dipende in gran parte dall'architettura software che scegli. In una buona architettura, questi test sono, per così dire, "poco interessanti", nel senso che non testano realmente le funzionalità effettive, ma si limitano a confermare di aver collegato i componenti di lavoro insieme correttamente.
Al di sopra di questo livello, inserisci il dominio dei test di accettazione. I test di accettazione sono generalmente concepiti in base ai requisiti funzionali e, a mio avviso, non trarrebbero alcun beneficio dall'analisi del percorso. Le tue difficoltà nascono dall'intrinseca fragilità dell'automazione di tali test. Ancora una volta, una buona architettura si appoggerebbe più pesantemente sulla verifica tramite test unitari.
Esempio
Genera test unitari per il tuo codice con IntelliTest
IntelliTest explores your code to generate test data and a suite of unit tests. For every statement in the code, a test input is generated that will execute that statement. A case analysis is performed for every conditional branch in the code. For example, if statements, assertions, and all operations that can throw exceptions are analyzed. This analysis is used to generate test data for a parameterized unit test for each of your methods, creating unit tests with high code coverage.
In breve, certo, puoi fare tutto questo a mano, ma una macchina può farlo meglio, più velocemente, più a fondo e con meno errori.