CppUnit per i file eseguibili di test unitario?

I processi esterni possono essere testati (come già detto da Doc Brown, non saranno test unit ) da strumenti di test in qualsiasi lingua. Quindi consiglio di usare un linguaggio in cui l'esecuzione di strumenti esterni è facile, quindi alcuni linguaggi di scripting piuttosto che C ++. Alcune opzioni sono:

• CTest fa parte di CMake. Esegue processi esterni con parametri specifici e ne controlla l'output e restituisce il valore. Le funzionalità sono piuttosto limitate, ma è utile eventualmente combinare test scritti con vari strumenti. E integrali nella build se usi CMake.
• Unix Shell (usando cygwin o msys su Windows). Puoi usare ShUnit o scrivere un po 'di colla personalizzata, nella shell è semplice.
• Expect è uno strumento appositamente progettato per testare i programmi da riga di comando. Supporta il terminale di emulazione per l'applicazione testata, quindi può essere utilizzato per testare applicazioni che richiedono l'interazione del terminale, che non può essere testato con ctest o shell.
• Esiste una versione Perl di Expect e un wrapper per semplificare gli usi semplici, Expect::Simple , oppure puoi usare Perl solo con lo standard test :: Harness .
• Python ha anche il modulo pexpect per lo stesso scopo e ha il vantaggio di essere meglio integrato in Windows.
• Sono sicuro che Ruby avrà anche questo strumento.
• Ci sono persino alcuni strumenti che possono automatizzare l'interazione con le applicazioni della GUI, come il Linux Testing Project Linux (che da quando ha imparato a controllare le applicazioni utilizzando anche i toolkit nativi di Windows e MacOS GUI.

Probabilmente utilizzerai il rispettivo framework "xUnit" con le lingue sopra menzionate e potresti farlo ugualmente con C ++. Gestirà i test in sequenza per te, ma gli strumenti di test che fornisce non saranno di grande utilità per te. Dovrai scrivere le tue asserzioni per verificare l'output o l'uso dei moduli previsti.

Nota che alcuni degli strumenti di cui sopra esistono molto più a lungo di qualsiasi xUnit. La prima versione di expect è stata creata nel 1987 e DejaGNU (framework di test su top of expect utilizzato da GCC e alcuni altri progetti GNU ) changelog risale al 1992 mentre potevo solo tracciare SUnit (Smalltalk, apparentemente il primo framework di test unitario) fino al 1997.

Un buon esempio di progetto con estesi test funzionali sull'interfaccia della riga di comando è gcc. Ha una vasta collezione di frammenti di codice che dovrebbero compilare e una vasta collezione di frammenti di codice che dovrebbero non compilare e la suite di test prova a compilarli con il compilatore appena creato e verifica se i risultati funzionano dove dovrebbero e che viene data la diagnosi appropriata per quelli che non dovrebbero essere compilati. La maggior parte degli altri compilatori e interpreti dispone di suite di test simili.

Un altro esempio sarebbe git, dove l'interfaccia primaria è anche a riga di comando e i test vengono eseguiti utilizzando il framework di shell personalizzato che utilizza il runner dal modulo perl Test, mentre non ha molto verso l'API di livello C che consentirebbe di eseguire test in stile test unitario.

Puoi utilizzare quasi qualsiasi strumento di test xUnit per il test automatico degli eseguibili (tuttavia, ciò non comporterà test unit , ma test di integrazione o di sistema). Ciò presuppone che l'eseguibile possa essere eseguito in alcune modalità batch senza l'interazione dell'utente e produrrà un output leggibile dalla macchina per il quale è possibile verificare se si tratta dell'output previsto o meno.

Basta scrivere un test che esegua il tuo eseguibile in un processo separato (vedi, ad esempio, qui ), inserisce l'output in un file e aggiunge una funzione alla lib test che confronta il contenuto del file con un secondo file" output previsto ". Potrebbe essere necessario aggiungere ulteriori misure di sicurezza come i test di time-out se si prevede che i file eseguibili si arrestino in modo anomalo o lascino la modalità batch in caso di errore.

Eseguire il processo separato è semplice, testare l'output, tuttavia, può essere complesso arbitrario, dipende dal tuo programma sotto test e dalla complessità del suo output. Ma la seconda parte non è nulla che ti aspetti uno strumento xUnit con cui aiutarti.