[解決済み] シェルスクリプトのユニットテスト

質問

私が長年にわたって取り組んできたほとんどすべての製品は、あるレベルのシェル スクリプト (または Windows のバッチ ファイル、PowerShell など) を含んでいました。 コードの大部分を Java または C++ で書いたとしても、シェル スクリプトで行った方が良い統合またはインストール タスクが常にあるように思えました。

したがって、シェル スクリプトは出荷されたコードの一部となり、コンパイルされたコードと同様にテストされる必要があります。 誰か、次のようなシェル スクリプト ユニット テスト フレームワークの経験をお持ちですか。 shunit2 ? 私は今のところ主に Linux シェル スクリプトに興味があります。テスト ハーネスが他の xUnit フレームワークの機能と使いやすさをどれだけ重複しているか、そして CruiseControl や Hudson などの継続的ビルド システムとどれだけ簡単に統合できるかを知りたいと考えています。

どのように解決するのですか？

2019-03-01に更新しました。私の好みは バット になりました。小さなプロジェクトで数年間使っています。きれいで簡潔な構文が好きです。CI/CDフレームワークと統合したことはありませんが、その終了ステータスはスイートの全体的な成功/失敗を反映しており、以下に述べるようにshunit2よりも優れています。

前回の回答

私が使っているのは シャニット2 をLinux環境でのJava/RubyのWebアプリケーションに関連するシェルスクリプトに使っています。 使いやすく、他の xUnit フレームワークと大きく異なる点はありません。

CruiseControlやHudson/Jenkinsとの統合は試していませんが、他の手段で継続的インテグレーションを実装する際に、これらの問題に遭遇しています。

• 終了ステータス。テストスイートが失敗したとき、shunit2 は失敗を伝えるために非ゼロの終了ステータスを使用しません。 そのため、テストスイートの合否を判断するために shunit2 の出力を解析するか、継続的インテグレーションフレームワークが期待するように、合否を exit status で伝えるように shunit2 を変更しなければなりません。
• XML ログ: shunit2 は JUnit スタイルの XML ログを生成しません。