ACTUALIZACIÓN 2019-03-01:Mi preferencia ahora son los murciélagos. Lo he usado durante algunos años en pequeños proyectos. Me gusta la sintaxis limpia y concisa. No lo he integrado con marcos de CI/CD, pero su estado de salida refleja el éxito/fracaso general de la suite, que es mejor que shunit2 como se describe a continuación.
RESPUESTA ANTERIOR:
Estoy usando shunit2 para scripts de shell relacionados con una aplicación web Java/Ruby en un entorno Linux. Ha sido fácil de usar y no se ha apartado mucho de otros frameworks xUnit.
No he intentado integrarme con CruiseControl o Hudson/Jenkins, pero al implementar la integración continua por otros medios me he encontrado con estos problemas:
- Estado de salida:cuando falla un conjunto de pruebas, shunit2 no usa un estado de salida distinto de cero para comunicar la falla. Por lo tanto, debe analizar la salida de shunit2 para determinar la aprobación/rechazo de una suite, o cambiar shunit2 para que se comporte como esperan algunos marcos de trabajo de integración continua, comunicando la aprobación/rechazo a través del estado de salida.
- Registros XML:shunit2 no produce un registro de resultados XML estilo JUnit.
Me pregunto por qué nadie mencionó a los MURCIÉLAGOS. Está actualizado y cumple con TAP.
Describa:
#!/usr/bin/env bats
@test "addition using bc" {
result="$(echo 2+2 | bc)"
[ "$result" -eq 4 ]
}
Ejecutar:
$ bats addition.bats
✓ addition using bc
1 tests, 0 failures