MISE À JOUR 2019-03-01 :Ma préférence va aux chauves-souris maintenant. Je l'utilise depuis quelques années sur de petits projets. J'aime la syntaxe claire et concise. Je ne l'ai pas intégré aux frameworks CI/CD, mais son statut de sortie reflète le succès/l'échec global de la suite, qui est meilleur que shunit2 comme décrit ci-dessous.
RÉPONSE PRÉCÉDENTE :
J'utilise shunit2 pour les scripts shell liés à une application Web Java/Ruby dans un environnement Linux. Il a été facile à utiliser et ne s'écarte pas beaucoup des autres frameworks xUnit.
Je n'ai pas essayé d'intégrer CruiseControl ou Hudson/Jenkins, mais en mettant en œuvre l'intégration continue par d'autres moyens, j'ai rencontré ces problèmes :
- État de sortie :lorsqu'une suite de tests échoue, shunit2 n'utilise pas un état de sortie différent de zéro pour communiquer l'échec. Vous devez donc soit analyser la sortie de shunit2 pour déterminer la réussite/l'échec d'une suite, soit modifier shunit2 pour qu'il se comporte comme certains frameworks d'intégration continue s'y attendent, en communiquant la réussite/l'échec via l'état de sortie.
- Journaux XML :shunit2 ne produit pas de journal de résultats XML de style JUnit.
Je me demande pourquoi personne n'a mentionné BATS. Il est à jour et conforme TAP.
Décrivez :
#!/usr/bin/env bats
@test "addition using bc" {
result="$(echo 2+2 | bc)"
[ "$result" -eq 4 ]
}
Exécuter :
$ bats addition.bats
✓ addition using bc
1 tests, 0 failures