「何かが設定ミスだ」と気づく最初のきっかけが、失敗したCI実行であってはいけません。
TestSpriteをCIに組み込む前に、testsprite doctorを実行してください。APIキー、ネットワークアクセス、CLIバージョンがすべて正しく設定されているかを確認します — つまらないセットアップの問題が、本物のテスト失敗を装うことがなくなります。
すでに使っている同じCLIに組み込み済み
APIキーを検証する
testsprite doctorは、CIジョブが認証エラーで最初の実行を無駄にする前に、TESTSPRITE_API_KEYが設定されていて有効かどうかを確認します。
ネットワークとプロキシへのアクセスをチェック
企業のプロキシやロックダウンされたCIランナーは、発信リクエストを静かにブロックすることがあります。Doctorは、パイプラインの途中で気づく前に、CLIが実際にTestSpriteに到達できるかを確認します。
CLIバージョンを確認する
インストールされているものとパイプラインが期待するものとのバージョンの不一致は、製品のバグのように見える形で失敗することがあります。Doctorはそれが起きる前にフラグを立てます。
どこでも実行できる
ローカルでセットアップしているときも、新しいCIジョブを配線しているときも、チームメイトのパイプラインが認証できない理由をデバッグしているときも、同じチェックです。
$ testsprite doctor Checking environment... ✓ API key found and valid ✓ Network access to TestSprite confirmed ✓ CLI version up to date → environment looks good, ready to run tests $ testsprite doctor Checking environment... ✗ TESTSPRITE_API_KEY not set ✗ Network request blocked — check proxy configuration → fix these before running testsprite test run
設定のデバッグをCIに任せない
テストにたどり着く前に失敗するパイプラインは、何もテストしていません — ただ大きな音を立てて失敗しているだけです。先にtestsprite doctorを実行すれば、「なぜCIが失敗したのか」を2秒で答えられる問いに変えられます。
TestSpriteをCIに組み込むために
CIを配線する前に実行する
testsprite doctorをパイプラインの最初のステップとして追加してください — インストール直後、testsprite setupや本物のテスト実行より前です。
testsprite setupと組み合わせる
testsprite setup --from-env --yes --agent <name>で認証情報を非対話的に設定し、その後doctorを実行して実際に機能しているかを確認します。
無料でオープンソース
npm install -g @testsprite/testsprite-cliでCLIが手に入ります。Apache-2.0ライセンスなので、最初のチェックを妨げるものは何もありません。
機械可読な出力
--output jsonを渡せば、パイプラインが自動的にパースして動作できる形式で結果を取得できます。
世界中の企業から信頼されています
"TestSpriteは豊富なテストケース生成、明確な構造、読みやすいコードを提供します。また、新しいテストケースを生成して迅速に拡張できるシンプルなオンラインデバッグもサポートしています。"
"TestSpriteの自動化により、膨大な手作業を削減できています。開発者は開発プロセスの早い段階でバグを簡単に発見し、解決することができます。"
よくある質問
testsprite doctorは実際に何をチェックしますか？
APIキーが設定されていて有効かどうか、CLIがネットワーク経由で(プロキシ越しも含めて)TestSpriteに到達できるかどうか、そしてインストール済みのCLIバージョンが最新かどうかをチェックします。
いつ実行すべきですか？
CLIをインストールした直後、そして新しいCIパイプラインの最初のステップとしてもう一度 — testsprite setupや本物のテスト実行より前に実行することで、設定の問題がパイプラインの途中ではなく早い段階で失敗します。
単にテストを実行して何が壊れるか見るのと、何が違いますか？
APIキーの欠落やネットワークリクエストのブロックが原因の失敗したテスト実行は、深く調べるまで本物の製品の失敗と見分けがつきません。Doctorは、実行を無駄にする前に「あなたのセットアップが壊れている」のか「あなたの製品が壊れている」のかを切り分けます。
CIで動作しますか、それともローカル専用ですか？
どちらでも動作します — 同じコマンドです。セットアップ中はローカルで実行し、パイプライン環境でのプロキシや認証情報の問題を見逃さないよう、CIステップとしてもう一度実行してください。
問題が見つかった場合はどうなりますか？
何が間違っているか — 欠落したTESTSPRITE_API_KEY、ブロックされたネットワーク経路、古いCLIバージョンなど — を教えてくれるので、始まる機会すらなかったテスト実行をデバッグするのではなく、その1つの問題を修正できます。