テストツール:各レイヤーだけが検出できるもので描くマップ

固有の検出範囲で分類するテストツールのマップ

これら3つのレイヤーの周囲には、3つの専門的なツールが位置します: コントラクトテスト は独立してデプロイされたサービス間の形式のずれを、 負荷テスト はキャパシティを、 セキュリティスキャン は既知の脆弱性の分類を、それぞれ検出します。いずれも主要な3つのレイヤーでは捉えられないものを検出しますが、どれもその代わりにはなりません。

空白が生まれやすいのはどこか

多くのチームはユニットテストとある程度のエンドツーエンドのカバレッジを持ち、その中間が薄くなっています。これは順序が逆です。APIレイヤーは、その上のレイヤーよりもはるかに低いコストで、ユーザーから見える欠陥の大半を検出するからです。

2つ目のよくある空白は、カバレッジがコード量に追いつかないことです。これは別のツールカテゴリを追加しても解決しません。解決するのは、誰かが書ける量に左右されないカバレッジです。

機能比較表よりも有効な問い

どのレイヤーのツールを検討している場合でも、失敗が修正する人の目にどう映るか、そしてアサーションに到達しないまま終わった実行が成功として報告されるかどうかを問うてください。この2点は、比較ページに載っているどの情報よりも、そのツールの価値をよく予測します。

すでに持っていて、使っていないツール

何かを追加する前に、すでに導入されたまま使われていないものを確認する価値があります。多くの組織は、実際に使っている以上のテスト能力をすでに持っているからです。

たいていは、2年前に書かれた数件のテストだけが残るユニットテストフレームワークがあります。毎晩実行されているのに誰も結果を見ないブラウザテストのスイートがあることも多くあります。通知をミュートしたチャンネルにレポートを送り続けるスキャナーがあることも珍しくありません。それぞれ理由があって導入され、理由があって使われなくなりました。同じカテゴリにもう一度お金をかける前に、その理由を知っておく価値があります。

よくある答えは、誰も対応しない出力は無視されるようになる、というものです。これはツールの問題ではなくプロセスの問題です。新しいツールは同じプロセスを引き継ぎ、同じ場所にたどり着きます。ただし、より遅く、より高いコストをかけて。

次の1時間をどこに使うか

1. 壊れたら恥ずかしいと感じるフローを、エンドツーエンドでカバーします。

2. その背後にあるAPIを、異常系のケースも含めてカバーします。

3. 直近に壊れたものを、恒久的なチェックに変えます。

ローカルへのインストールを避けたい場合は、ダッシュボードが同じ範囲をカバーします。コマンドの全体像は CLIリポジトリにまとまっています。

• GitHub App は、TestSpriteのダッシュボードで設定するWebhookです。パイプラインがすでに発行しているデプロイイベントを待ち受けるため、リポジトリ側には何の変更も必要ありません。

• GitHub Actions を使えば、ターミナルから設定して、自社のワークフローの中にこのステップを組み込めます。

TestSpriteはこのマップのどこに位置するか

APIレイヤーとエンドツーエンドレイヤーです。ユーザーから見える欠陥の大半が存在し、かつよくある空白が生じるのが、この2つです。モックではなく実際に動作している製品に対して実行し、皆さんのソースと探索の実行結果からカバレッジを生成し、平易な言葉で調整できます。

Auto-Authenticationは実行全体を通してセッションを維持し、Dynamic Variablesは呼び出し間で値を引き渡し、Dependency Chainsは実行順序を導き出し、Auto-Cleanupはその実行が作成したものだけを正確に削除します。ブラウザ操作のステップはセレクタではなく意図として表現されるため、デザイン変更でスイートが赤くなることはありません。

ユニットテストは引き続き皆さんのものであり、最も安価なフィードバックであり続けます。コントラクトテスト、負荷テスト、セキュリティスキャンは、別個の手段のままです。利点は、リリース作業と競合するような記述の負担を増やすことなく、薄かった中間層が埋まることです。