Tengo una gran colección de utilidades de línea de comandos que nos escribimos y usamos con frecuencia. Por el momento, probarlos es muy engorroso y, en consecuencia, no hacemos tantas pruebas como lo deseamos.¿La mejor manera de probar herramientas de línea de comandos?
Me pregunto si alguien puede sugerir buenas técnicas o herramientas para hacer un buen trabajo de este tipo.
Editar: para aclarar este es UNIX
Gracias de antemano. Tom
Aruba es una extensión Cucumber para probar aplicaciones de línea de comandos escritas en cualquier lenguaje de programación.
Para usarlo, necesitará ruby para ejecutar las pruebas, pero el propósito de aruba es proporcionar una biblioteca de definiciones de paso predefinidas para que no tenga que escribir ningún código ruby para hacer una prueba viable suite. (. Aunque en algún momento es probable que desee escribir un poco de rubí para hacer unos pasos personalizados)
Se puede ver un ejemplo sofisticado de una herramienta de línea de comandos probado con Aruba aquí: jingweno/gh
Debería poder llamarlos desde un script de shell (archivo por lotes, en sistemas operativos MS), redirigir el resultado a un archivo, luego escanear el archivo programáticamente para asegurarse de que tiene el resultado correcto. No conozco un marco de prueba que lo automatice, pero debería ser bastante sencillo configurarlo usted mismo.
Sí, esperaba que alguien conociera un marco o herramienta. Estaba pensando en derribar uno yo mismo como si fuera tu derecho, no sería demasiado difícil. Saludos. Tom –
Puede hacerlo desde un archivo de proceso por lotes o desde el servidor de secuencias de comandos de Windows.
Pero prometo usar un planificador de tareas como (http://www.splinterware.com/products/wincron.htm) u otro software gratuito/profesional.
Allí puede copiar/pegar fácilmente los parámetros de la línea de comandos, que debe variar cuando quiere probar su software unas 100 veces?
Hice un poco de esto (hace muuuucho tiempo jeje) usando Expect para comprobar que lo que ocurrió fue lo que, umm, esperaba
Recomiendo la estructuración de código de la herramienta de línea de comandos para que la utilidad de línea de comandos es un cliente de una biblioteca de funciones y/o clases.
En lugar de simplemente usar std :: cout para imprimir la salida, haga que la función de bibliotecas tome una referencia ostream que por defecto es std :: cout. Cuando esté probando, proporcione un std :: stringstream para recopilar el resultado.
Finalmente, simplemente compare la salida de su utilidad con los resultados esperados usando su marco de prueba de unidades favorito.
(Pido disculpas por el ejemplo específico de C++ ... Estoy seguro de que también hay maneras de hacer cosas similares en otros idiomas).
Usted podría use perl con la biblioteca Test::more, que proporciona un excelente marco para probar CLI. Aunque se diseñó principalmente para pruebas unitarias, podría ampliarlo para probar los flujos de trabajo de los usuarios.
Algunos de los métodos:
# 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);
Usando Cram puede escribir pruebas que se asemejan a una sesión de consola interactiva. Cram repetirá los comandos de la prueba, comparará la salida con la referencia e informará las diferencias. El formato de las pruebas es bastante flexible y le permite hacer coincidir la salida utilizando Perl regex o comodines con forma de shell.
Bats (Bash Automated Testing System) por Sam Stephenson. Es minúsculo, está escrito únicamente en concha y tiene un buen conjunto de características.
sugerido anteriormente Aruba parece interesante, pero en algunos casos podría ser una exageración tranquila en términos de dependencias (rubí, pepino)
¿Está utilizando o escribir/producir las utilidades de línea de comandos? –