テスティング・スカイスクレイパーとは、テストピラミッドの段階的な比率に代えて、どの層のテストも良いものであり、有用であればどの層でも大量に書いてよいという立場をとるテスト戦略である。ピラミッドが、上位の層は実行が遅く保守コストが高いという理由から、テストのおよそ 70〜80% を単体テスト層に、15〜25% を結合テストに、5〜15% を E2E テストに割り当てるのに対し、スカイスクレイパーはどの種類のテストも GOOD であり、どれを多く書いても構わないとする。
用法
コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計 は、コーディングエージェントの導入によってコミット数がおよそ倍増した後、ピラミッドの論理がなお当てはまるのかを問うことでこの戦略にたどり着いたチームについて、この用語を採用している。同記事の主張は、エージェント駆動開発のもとではコードが急速に変化し、パッケージや依存関係の更新も頻繁になるため、単体テストだけでは十分な保証にならなくなり、ピラミッドのコストに関する反論がなお有効かどうかが問題になる、というものである。
同記事の答えは、反論のうち一方はおおむね解消し、もう一方は解消していない、というものである。歴史的に上位の層を薄く保つ理由だった保守コストは、その圧力を生み出したのと同じエージェントによってほぼ解決されるという。コードを変更したら必ずテストも更新するようエージェントに指示するガイドラインがあれば、エージェントは概ね促されなくともそうするからである。実行時間は解決されておらず、同記事が示す対処法は抑制ではなくスケジューリングである。プルリクエストが作成されたときには軽量なテストだけを実行し、重い E2E テストスイートはマージキューを使ってレビュー承認後まで遅らせる。こうすることで、開発者を待たせることなく、メインブランチに到達するものは依然として完全に検証された状態に保たれる。
報告されている成果は、特にバックエンドチームについてのもので、テストとコードの行数比が 2025 年 6 月の 78.6% から 9 月には 95.2%、12 月には 112.6% へと上昇し、コードよりもテストの行数のほうが多くなった。あわせて、エンドユーザーが触れる API とバッチ処理について E2E テストと結合テストを完全に網羅するに至り、これはコーディングエージェントの導入から 6 か月以内に達成されたという。
適用される場面
この戦略は、常に揃っているとは限らない 2 つのことを前提としている。1 つ目は、文書化されたガイドラインによって規律づけられたエージェント支援のワークフローである。保守に関する議論全体が、エージェントがコードとあわせて確実にテストを更新することに依拠しているからであり、それがなければピラミッド本来の反論はそのまま戻ってくる。2 つ目は、テストを選択的に、かつ異なるタイミングで実行できるインフラ、すなわちマージキューやそれに相当するものである。そうでなければ、同記事が未解決だと認めている実行時間のコストが、そのまま開発者の待ち時間にのしかかる。
同記事は、この戦略がどのように誤って適用されうるかについては論じていない。同記事が保持しているのは、コストと速度に関するピラミッドの根底にある論理である。保守と実行時間の問題は退けられるのではなく対処されており、そのため同記事が述べる変更は、その背後にある論理ではなく比率に対するものとなっている。
どの程度確立されているかについて言えば、この用語はチーム自身が考案したものではなく、同記事が引用する外部の記事に由来する。ここで報告されている内容はすべて、単一のモノレポにおいて 6 か月にわたって 1 つのチームがこれを採用した事例である。テスト比率の数値はそのチーム自身の計測値であり、エージェントが保守するテストによって保守に関する反論が解消するという主張は、そうしなかったチームとの計測された比較ではなく、そのチームの経験である。