Hurl 4.0.0 リリース
(hurl.dev)- Hurl 4.0.0は、curl ベースの CLI HTTP テストツールの新バージョンで、プレーンテキストファイルに記述した HTTP リクエストとレスポンス検証を実行するフローを改善
- HTML レポートは JavaScript を使わずインライン CSS のみを使う純粋な HTMLとして生成され、リクエスト/レスポンスごとのウォーターフォールタイムライン・実行ログ・インラインエラーをあわせて表示
--error-format longは失敗したテストのレスポンスヘッダーと本文を出力し、CI/CD デバッグで再実行なしに原因特定に必要な文脈を確認できるようにする- 新しい
decodeとxpathフィルターにより、文字セットが明確でないレスポンスバイトを直接デコードし、HTML の一部に対して XPath 検証を実行可能 - JSONPath の評価方法の一部が変更され、大文字条件を満たすカスタム HTTP メソッドをサポートしたことで、
QUERYのような新メソッドも試せる
Hurl 4.0.0 概要
- Hurl は curl ベースのコマンドラインツールで、シンプルなプレーンテキスト形式で定義した HTTP リクエストを実行する
- Hurl ファイルには、リクエスト、期待する HTTP ステータス、ヘッダー・証明書・JSONPath などの**検証（assert）**をあわせて記述できる
- Hurl 4.0.0 は、HTML レポート、エラー出力、フィルター、JSONPath の動作、カスタム HTTP メソッド対応を中心に変更された
HTML レポートとウォーターフォールタイムライン
- Hurl HTML report は、各実行ごとに 3 種類の情報を生成する
- ウォーターフォールタイムライン: 各リクエスト/レスポンスをグラフで表示し、DNS、TCP ハンドシェイク、time to first byte などの応答タイミングを確認できる
- 実行ログ: リクエスト/レスポンスヘッダーや証明書情報などを含む
- シンタックスハイライトされたソースファイル: エラーをインライン表示する
- レポートは JavaScript なしの純粋な HTMLとインライン CSS で構成され、GitLab CI/CD や GitHub Actions のような CI/CD 環境に統合しやすい
- ウォーターフォールタイムラインで使われるタイミングは
libcurlが提供し、--jsonオプションでも公開される--jsonは、エラー、assert、証明書、キャプチャ、Cookie、タイミングを含む構造化された実行情報を提供する- この JSON 出力を使って独自レポートを作成できる
可視化で明らかになった assert 性能ボトルネック
- リッチな可視化は隠れた性能問題を明らかにすることがある
- 一部の実行ではリクエスト間に大きな間隔が現れ、その原因は HTTP レスポンスに対する assert の数が非常に多かったためだった
- Hurl 4.0.0 時点での assert 計算はシンプルな方式で動作する
- 同じレスポンスに対する各 assert が独立して処理される
- assert ごとに最初からパースし、再計算する
- Hurl チームは
libcurlと Rust の組み合わせによる速度に自信を持っていたが、この事例をきっかけに次のリリースではassert 性能改善が必要だと判断した
CI/CD 向け詳細エラー出力
- 従来のテスト失敗出力は期待値中心だったため、分析に必要な情報が不足することがあった
- 新しい
--error-formatオプション で、より長いエラー説明を選べる --error-format longモードでは、レスポンスヘッダーとレスポンス本文が自動的にログへ残る- 例ではテストが
Control-Security-Policyヘッダーを探していたが、実際のレスポンスにはContent-Security-Policyがあった- レスポンスヘッダーと本文がログに含まれるため、タイプミス由来の問題を簡単に確認できる
- このオプションは、テストを再実行せずにセッションデバッグに必要な文脈を得たいCI/CD 環境で有用
- レスポンス本文まで記録するため、ログが非常に長くなる場合がある
新フィルター: decode と xpath
- Hurl のテキスト assert はレスポンス本文バイトを自動的にデコードし、その際に
Content-Typeレスポンスヘッダーのcharsetヒントを使う Content-Typeにエンコーディングがない場合や、HTML 文書内の<meta>タグに文字セットがある場合がある- 新しい
decodeフィルター は、バイト列を明示的にテキストへデコードして検証できるようにする- 例では GB2312 でエンコードされた本文を
bytes decode "gb2312"でデコードする
- 例では GB2312 でエンコードされた本文を
- 新しい
xpathフィルター は、レスポンスの一部に対してXPath 式を評価できるようにする- 例では
xpath "string(//body)"で HTMLbodyテキストを検証する
- 例では
JSONPath 評価方式の変更
- Hurl 4.0.0 は JSONPath クエリ評価の一部を変更した
- JSONPath には適切な正式仕様がなく、Hurl は事実上の標準として使われている
goessner.netの文書にできるだけ従おうとしている - 実装ごとに異なるエッジケースがある
- 標準的な JSONPath は常にコレクションを返すが、多くの場合あまり意味がなく、テストもしにくいことがある
- 一部実装は definite path のノード値と indefinite path のコレクションを区別する
- Hurl 4.0.0 で値を返す selector は 2 種類だけ
- 配列インデックス selector:
$.store.book[2] - オブジェクトキー selector:
$.store.bicycle.color,$.store.bicycle['color']
- 配列インデックス selector:
- フィルターを使う selector や
$[*].idのような selector はコレクションを返す- コレクションから値を取り出すには
nthフィルター を使える
- コレクションから値を取り出すには
カスタム HTTP メソッド
- Hurl 4.0.0 は任意のカスタム HTTP メソッドをサポートする
- メソッドは大文字で記述する必要がある
- 例として、新たに追加予定の
QUERYメソッドをすぐに試せる
リリースノートと参加のお願い
- そのほかの改善やバグ修正は release note で確認できる
- プロジェクトは GitHub star、Twitter での共有、改善要望、ユースケース共有を呼びかけている
1件のコメント
Hacker Newsの反応
Hurlの紹介が「curlベースのコマンドラインツールで、シンプルなプレーンテキスト形式で定義されたHTTPリクエストを実行する」から始まっているのがよかった
Hurlを初めて見たが、冒頭の短い紹介とコード例だけで今すぐインストールして試したくなったし、素晴らしいリリースに見える
たとえば
Hurl: Run HTTP requests in a simple plain-text formatのようなタイトルのほうがよかっただろうこれをAPIテストの業界標準にしてほしい
QAが送ってくるPostmanのスクリーンショットを見るのにも、修正後にQAがSendを押すまで待つのにもうんざりしているし、QAの側も開発者を待つのに疲れているはずだ
Hurlは開発者にもQAにも読み書きでき、自動化やCI統合が可能で、期待する挙動を伝えやすく、PRに一緒に入れてQAの出発点にもできるので、使える場面で使わない理由がないように思える
ワークフローごとのHTTPやり取りの流れを1つのhurlファイルにまとめられ、そのままGitに入るテストスイートになる
ただしHurlも非常に興味深く、この問題に対してはエディタに依存しない点がより良い解決策だという意見には同意する
JSで負荷/性能テストを書いてリポジトリにコミットでき、CIで簡単に自動化でき、複数のバックエンドにメトリクスを送れ、HTTP以外のプロトコルも使え、モダンなコマンドラインインターフェースと多くの機能を備えている
Postman-to-k6変換器もある: https://github.com/apideck-libraries/postman-to-k6
k6の思想は、単体/統合テストのように開発者がこうしたテストを書いて古典的なQA-開発サイクルを断ち切ることにあり、Hurlも良さそうだが、既存の性能テストツールより機能は限定的で、個人的には専用テキスト形式よりプログラミング言語でテストを書くほうを好む
ソースコードから仕様を生成するツールを使っていても、エンドポイントのメタデータを誤って定義するユーザーのミスは依然として起こり得るし、Dreddがそれを検出してくれる
これまで見たモダンなUnixプログラムの中でも、最良の例にかなり近い
標準入力を受け取り、標準出力に出し、ターミナルのあちこちにユニコード絵文字を乱用せず、manページもかなりよく整っている
hurlのファイル拡張子が3文字ではなく4文字なのもよくて、ようやくMS-DOS互換性の心配から解放された感じがする
真剣に使ってみる価値のあるツールに見える
コマンドラインHTTP処理ツールとしてはHttpieか、より高速なRustによる再実装版のXHがいちばん好きだ
curlよりずっとHTTPに近い構文でコマンドラインからリクエストを送れ、多くのオプションを覚える必要がない
すでにcurlに慣れているなら大きな利点はないかもしれないが、軽く使うにはずっと直感的だ
https://httpie.io/
https://github.com/ducaale/xh
Adaptiveではテスト自動化にhurl.devを広く使っている: https://adaptive.live
内部製品のフロー全体をHurlでテストしており、製品安定化の観点で組織に導入したものの中で最良の選択だった
デプロイ前のたびにオンボーディング、登録、主要フローなどを検証するHurlベースの自動テストを複数実行しており、コンテナ化されているので並列実行も可能だ
内部ツールもhurl.devの周辺に作っており、学びやすいためアナリストやビジネスユーザーでもテストを作れる点が気に入っている
テストという文脈では、Seleniumのようなブラウザベースのアプローチのほうがはるかに強力で、全体として有用に見える
ドキュメントを見たが、その点に関する記述は見つけられなかった
hurlをしばらく追っていたが、他のツールとの差別化ポイントは、テスト用の独自DSLを持っていることだ
単にHTTPリクエストを送るだけでなく、レスポンスを検証し、データをキャプチャできる
ただ、もしメンテナーが見ているなら、検証を外部スクリプトに委ねられるようにしてほしい
たとえば、項目コレクションのすべてのプロパティが同じ値かどうかを検証するには、まだ
nthセレクタを使わないと難しく、nth = *のような仕組みも必要だすべてのユースケースをDSLで提供するのは大仕事すぎるので、jsonpathの結果をjqに渡して、trueが返ったらテストを通す、といったことができるとよい
ただし、そうするとファイルの自己完結性が薄れ、かなり複雑な問題が生じる可能性もある
Hurlは急速に成長していて良さそうだ
エンドポイントのテストでは常に認証が必要だが、認証を1つのファイルに書いておき、トークンが必要な別のファイルの冒頭でそれを読み込む方法があるのか気になる
そもそも、そういう形で秘密情報を保存して使うのが最善なのかもはっきりしない
ドキュメントによれば、コマンドライン引数と環境変数を通じてhurlファイルに変数を渡せる: https://hurl.dev/docs/templates.html
この用途ではhttpyacもかなり気に入っている: https://httpyac.github.io
JSスクリプティング機能があるのでかなり似ており、コマンドラインインターフェースだけでなくVS Code統合も素晴らしい
.httpサポートとの互換性も高いJetBrainsは
.httpファイルからjUnitテストレポートを生成する無料のコマンドラインツールも提供しているVisual Studio 2022にも
.httpファイルで似た機能があることを知った: https://learn.microsoft.com/en-us/aspnet/core/test/http-file...Hurlのほうが機能はずっと多そうだ