- runnの特徴
- シナリオベースのテストをするツールとして最適化されている（As a tool for scenario based testing）
- Goのコードのテストにテストヘルパーとして組み込むことができる（As a test helper package for the Go language）
- シンプルなワークフローエンジンとしての機能を有している（As a tool for workflow automation）
- HTTPリクエストだけでなくgRPCコール、データベースクエリ、リモートやローカルでの任意のコマンド実行にも対応している（Support HTTP request, gRPC request, DB query and SSH/Local command execution）
- シナリオ内のHTTPリクエスト（やgRPCコール）をOpenAPI Documentライクなシンタックスで書くことができる（OpenAPI Document-like syntax for HTTP request testing）
- [コラム] runnの名前の由来
runnは、筆者が開発しているオペレーション自動化ツール・パッケージです。
runnのロゴ
ここでいう「オペレーション自動化」とは「Runbook Automation」といわれる領域のことを指します。
Wikipediaによると、「Runbook」とはコンピュータシステムやネットワークに対してシステム管理者やオペレーターが実施する定型の手順や操作をまとめたものことを指すそうです[1]。
そこから転じて、Runbook Automationは運用作業の自動化を行うソリューションのことを指すようです。
Runbook Automationの範囲はとても広大ですが、runnのスコープは限定的です。
runnが想定している主なユースケースは次のようなものになります。
- APIのシナリオテスト（HTTP/gRPC）
- 任意のコマンドやHTTP/gRPCリクエスト、データベースクエリを実行可能なワークフローエンジン
- データベース操作等のオペレーションの実行と記録
Runbook Automationとしては2がもっともそれらしいユースケースですが、現在runnの開発メンバーが力を入れているのは1になります。
なので、runnはAPIシナリオテスティングツール・パッケージとも言えるでしょう。
runnの特徴
runnの特徴は次のとおりです。
シナリオベースのテストをするツールとして最適化されている（As a tool for scenario based testing）
たいてい、シナリオテストのシナリオは1つ以上のステップで構成されています。また、それぞれのステップは「ステップ1のレスポンスをステップ2とステップ3で使用する」というように関連しています。
runnはシナリオテストを構成するための機能を標準で持っています。
例えば、runnはシナリオの各ステップの実行結果（HTTPレスポンスやデータベースクエリの結果）は特に何も設定せずとも全て自動で記録され、そのまま次のステップで使用できます。
Goのコードのテストにテストヘルパーとして組み込むことができる（As a test helper package for the Go language）
runnはCLIツールであると共に、Goのパッケージでもあります。
go test で実行するテストにシナリオテストの仕組みを導入するための機能を標準で持っています。
net/http/httptest パッケージなどと組み合わせることでAPIシナリオテストのための強力なテストヘルパーとして機能します。
シンプルなワークフローエンジンとしての機能を有している（As a tool for workflow automation）
単純に順番にステップを実行するだけでなく、シンプルなワークフローエンジンとして活用するための機能も備えています。
- ステップのループ実行やリトライ
- 条件によるシナリオやステップのスキップ
- 前のステップが実行されたかどうかを条件にしたステップ実行
- 他のシナリオファイルを読み込んでの再利用
など。
HTTPリクエストだけでなくgRPCコール、データベースクエリ、リモートやローカルでの任意のコマンド実行にも対応している（Support HTTP request, gRPC request, DB query and SSH/Local command execution）
runnのシナリオファイル（ランブックと呼びます）はYAMLフォーマットで記述します。
HTTPリクエスト、gRPCコール、データベースクエリ、リモートやローカルでの任意のコマンド実行をシームレスに混在させて1つのランブックを作成できます。
シナリオ内のHTTPリクエスト（やgRPCコール）をOpenAPI Documentライクなシンタックスで書くことができる（OpenAPI Document-like syntax for HTTP request testing）
runnはシナリオファイルの「書き味」にもこだわりを持っています。
例えば、HTTPベースのAPIのスキーマドリブン開発のスタンダードともいえるOpenAPI Documentに近いYAMLシンタックスでHTTPリクエストのシナリオを書くことができます。
[コラム] runnの名前の由来
runnは「Run-N」つまり「N個のステップを実行する」「N個のシナリオを実行する」「N種類のランナーがある」という意味を持っています。読み方もそのまま「ランエヌ」です。
実は、当初runnは「Runbook」を短くした「runbk」という名前でした。
なぜ「Runbook」なのか。
runnは開発初期からAPIのシナリオテストをユースケースとしていましたが、合わせて汎用的な自動化の仕組みとしても使えるようにもしたいと考えていました。
そのため「Runbook（操作手順書）」という単語をツールの名前に採用したのです。
ただ、私にはどうも「runbk」という名前にしっくりきていませんでした。
とはいえ特に良い名前を思いつくわけでもなかったので悶々としながら開発をしていました。
あるとき「複数のシナリオを実行する」という機能を開発しているときに RunN という関数名を思いつき、その関数名を見て「これだ！」となったのでした。
そしてリポジトリもリネームし、晴れて「runn」となったのです。