Il modo migliore per testare gli strumenti da riga di comando?

Question

Ho una vasta collezione di utilità da riga di comando che scriviamo noi stessi e usiamo frequentemente. Al momento, testarli è molto complicato e di conseguenza non facciamo tutti i test necessari.

Mi chiedo se qualcuno possa suggerire buone tecniche o strumenti per fare un buon lavoro con questo genere di cose.

Edit: per chiarire questo è UNIX

Grazie in anticipo. Tom

Answer 1

Aruba è un'estensione Cucumber per il test delle applicazioni della riga di comando scritte in qualsiasi linguaggio di programmazione.

Per utilizzarlo, è necessario ruby ​​per eseguire i test, ma lo scopo di Aruba è quello di fornire una libreria di definizioni di passo predefinite in modo che non sia necessario scrivere alcun codice rubino per effettuare un test praticabile suite. (. Anche se ad un certo punto probabilmente si vuole scrivere un po 'di rosso rubino a fare qualche passo personalizzati)

Si può vedere un esempio di sofisticata di uno strumento a riga di comando testati con aruba qui: jingweno/gh

Answer 2

Dovresti riuscire a chiamarli da uno script di shell (file batch, su sistemi operativi MS), reindirizzare l'output in un file, quindi eseguire la scansione del file a livello di codice per assicurarti che abbia l'output corretto. Non sono a conoscenza di un framework di test che lo automatizza per te, ma dovrebbe essere abbastanza semplice da configurare da solo.

Answer 3

È possibile eseguire questa operazione da un file batch oder windows scripting host.

Ma prometto di utilizzare un programma di pianificazione come (http://www.splinterware.com/products/wincron.htm) o altro software gratuito/professionale.

È possibile copiare/incollare facilmente i parametri della riga di comando su cui si deve variare, quando si desidera testare il software per circa 100 volte ?!

Answer 4

ho fatto un po 'di questo (un moooolto tempo fa, hehe) utilizzando Expect per verificare che quello che è successo è stato quello che, umm, aspettavo

Answer 5

mi consiglia di strutturare il codice del tuo strumento da riga di comando in modo che l'utilità della riga di comando è un client per una libreria di funzioni e/o classi.

Piuttosto che usare semplicemente std :: cout per stampare l'output, fare in modo che la funzione librerie abbia un riferimento ostream che di default è std :: cout. Quando si esegue il test, fornire uno std :: stringstream per raccogliere l'output.

Infine, è sufficiente confrontare l'output del programma di utilità con i risultati previsti utilizzando il framework di test dell'unità preferito.

(Mi scuso per l'esempio specifico di C++ ... Sono sicuro che ci sono modi per fare cose simili anche in altre lingue).

Answer 6

Si potrebbe usa perl con la libreria Test::more, che fornisce un ottimo framework per testare le CLI. Sebbene progettato principalmente per il test delle unità, è possibile estenderlo per testare i flussi di lavoro degli utenti.

Alcuni dei metodi:

# Various ways to say "ok" 
    ok($got eq $expected, $test_name); 
    is ($got, $expected, $test_name); 
    isnt($got, $expected, $test_name); 

    # Rather than print STDERR "# here's what went wrong\n" 
    diag("here's what went wrong"); 

    like ($got, qr/expected/, $test_name); 
    unlike($got, qr/expected/, $test_name); 

    cmp_ok($got, '==', $expected, $test_name); 

command-lineautomationtestingperl-testing

Answer 7

Usando Cram è possibile scrivere i test che assomigliano a una sessione shell interattiva. Cram riprodurrà quindi i comandi dal test, confronterà l'output con il riferimento e segnalerà le differenze. Il formato dei test è abbastanza flessibile e consente di abbinare l'output usando espressioni regolari Perl o caratteri jolly simili a shell.

Answer 8

Bats (Bash Automated Testing System) di Sam Stephenson. È piccolo, scritto puramente nella shell e ha un bel set di funzionalità.

suggerito in precedenza Aruba sembra interessante, ma in alcuni casi potrebbe essere tranquillo un peso inutile in termini di dipendenze (rubino, cetrioli)