ここ数年、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへと移行しています。このアプローチには、各コンポーネントの独立したデプロイ、スケーリング、保守、および複数のチーム間での開発の並列化など、多くの利点があります。しかし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されていたテスト戦略を見直す必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテスト複雑性を管理するためのいくつかのアプローチ、および複数のチームがそれぞれ異なるサービスの管理者として行動しているにもかかわらず、テストとアプリケーションの正確性を維持する方法について説明します。

「テストピラミッド」とは、ソフトウェアテストを異なる粒度のバケットにグループ化する方法を示すメタファーです。また、これらの各グループにどれだけのテストを含めるべきかについてのアイデアも提供します。テストピラミッドの概念はしばらく前から存在していますが、チームは依然として適切に実践することに苦労しています。この記事では、テストピラミッドの元の概念を見直し、それを実践する方法を示します。ピラミッドの異なるレベルでどのような種類のテストを探す必要があるかを示し、それらをどのように実装できるかについて実践的な例を示します。

Ruby on Railsの開発者であるDavid Heinemeier Hanssonは、RailsConfでの基調講演で、TDDはもう死んだと宣言しました。これは、Railsコミュニティとより広いソフトウェア開発コミュニティの両方で、予想通り多くの論争を引き起こしました。また、David、Kent、そして私自身の間で興味深い会話にもつながりました。私たちは、これらの会話は他の人々も見てみたいと思うほど興味深いものであると判断し、ソフトウェア開発におけるTDDの役割について議論する一連のビデオハングアウトを録画しました。

ソフトウェアシステムにおけるオブザーバビリティは常に価値があり、クラウドとマイクロサービスの時代にはさらに重要になっています。しかし、システムに追加するオブザーバビリティは、低レベルで技術的な性質のものが多く、あまりにも頻繁に、コードベースにさまざまなロギング、インストルメンテーション、分析フレームワークへの粗雑で冗長な呼び出しを散りばめる必要があるように見えます。この記事では、この混乱を解消し、クリーンでテスト可能な方法でビジネス関連のオブザーバビリティを追加できるパターンについて説明します。

2014年初頭に、Appleの「goto fail」バグとOpenSSLの「Heartbleed」バグという2つのコンピューターセキュリティ上の欠陥が発見されました。どちらも広範囲にわたる深刻なセキュリティ障害を引き起こす可能性があり、その全容は永遠にわからないかもしれません。その深刻さを考えると、ソフトウェア開発業界は、それらをどのように検出できたかを振り返り、将来このような欠陥を防ぐ能力を向上させることが重要です。この記事では、単体テストが果たせる役割を検討し、単体テスト、そしてより重要なこととして単体テスト文化が、これらの特定のバグをどのように特定できたかを示します。さらに、そのような文化のコストとベネフィットを見て、Googleでそのような文化がどのように浸透したかを説明します。

自動化された回帰テストスイートは、ソフトウェアプロジェクトで重要な役割を果たすことができます。これは、本番環境での欠陥を削減するだけでなく、進化的な設計に不可欠です。開発チームと話をしていると、非決定的なテスト（時によって成功し、時によって失敗するテスト）の問題についてよく聞きます。非決定的なテストは制御されないまま放置されると、自動化された回帰テストスイートの価値を完全に破壊する可能性があります。この記事では、非決定的なテストに対処する方法の概要を示します。最初は、隔離することで他のテストへの損害を軽減するのに役立ちますが、それでもすぐに修正する必要があります。したがって、非決定性の一般的な原因である分離の欠如、非同期動作、リモートサービス、時間、およびリソースリークに対する治療法について説明します。

開発者がAPIからのJSON出力の画面を次々と誇らしげに見せている「デモ」に参加したことはありますか？ユーザーは混乱して気を散らし、意味を理解できませんでしたか？開発中にAPIを使用しようと試みて、機能をテストするために正しいJSONペイロードとヘッダーの呪文を見つけるのがいかに難しいかに悩まされたことはありますか？デモフロントエンドは、そのようなAPIをデモンストレーションおよび調査するための基本的な機能を提供するシンプルなUIです。

LLMエンジニアリングは、プロンプト設計やプロンプトエンジニアリングだけではありません。この記事では、最近のプロジェクトでプロトタイプのLLMアプリケーションを迅速かつ確実に提供するのに役立ったエンジニアリングプラクティスのセットを紹介します。LLMアプリケーションの自動テストと敵対的テスト、リファクタリング、およびLLMアプリケーションと責任あるAIのアーキテクチャに関する考慮事項について、手法を紹介します。

「モックオブジェクト」という用語は、テストのために実際のオブジェクトを模倣する特別なケースのオブジェクトを表すために人気のある用語になっています。ほとんどの言語環境には、モックオブジェクトの作成を容易にするフレームワークがあります。しかし、しばしば認識されていないのは、モックオブジェクトは特別なケースのテストオブジェクトの1つの形態にすぎず、異なるスタイルのテストを可能にするということです。この記事では、モックオブジェクトの動作、動作検証に基づくテストをどのように促進するか、そしてそれらを取り巻くコミュニティがそれらを使用して異なるスタイルのテストを開発する方法を説明します。

JavaScriptコミュニティでは、非同期コードのテストには、「通常の」同期コードのテストとは異なるアプローチが必要であるという誤解が一般的です。この記事では、それが一般的に当てはまらない理由を説明します。非同期動作をサポートするコードユニットのテストと、本質的に非同期であるコードのテストの違いを強調します。また、Promiseベースの非同期コードが、非同期動作を検証しながら、明確で読みやすい方法でテストできるクリーンで簡潔な単体テストにどのように適しているかを示します。

継続的デリバリーの概要（1時間）を提供します。トピックには、継続的デリバリーの正当性、デプロイメントパイプライン、継続的インテグレーション、DevOps、およびデプロイメント戦略が含まれます。ハイライトは、Jezによるリリース候補のギリシャ神話のヒーローとしての擬人化です。

最新のモックツールがレガシーコードの作業能力に及ぼすプラスの効果と、それらのツールを使用することによる潜在的なマイナス面。

従来、QAは、本番環境へのリリースの準備ができているかどうかを確認するために、リリース前にソフトウェアのテストに焦点を当てています。しかし、ますます多くの最新のQA組織は、本番環境で実行されているソフトウェアにも注目しています。ログやその他の監視ツールを分析することにより、開発組織に強調表示する品質上の問題を見つけます。このアプローチは、新しいバージョンのソフトウェアを迅速かつ確実に本番環境に投入するために継続的デリバリーを使用する組織で特に有効です。

テストインパクト分析（TIA）は、ビルドのテスト自動化フェーズを高速化する現代的な方法です。これは、ソースコードのコールグラフを分析して、本番コードの変更後に実行する必要があるテストを特定することによって機能します。Microsoftはこのアプローチについて広範な作業を行っていますが、開発チームは比較的安価に役立つものを実装することも可能です。

同僚のJoe Walnesが指摘してくれたように、同僚のChris Stevensonが開発した非常にシンプルなツールです。TextDox（AgileDoxの一部）は、JUnitテストケースからドキュメントを自動的に生成するツールです。ばかげているように聞こえますが、それはWardishのアイデアがそのようなものだからです。

友人の友人の話です。少なくともどこかで真実であるはずです。

コードで現在の日付や時刻を取得する必要がある場合、そのデータに対して直接システムルーチンにアクセスしないでください。「現在の日付/時刻」を特定の値にオーバーライドできるように、何らかのラッパーを適用してください。これはテストを簡素化するために重要です。

最近興味深い対比を見つけました。規模が似ている（約10万行）2つのエンタープライズアプリケーションプロジェクトで、環境もJavaと.NETと似ています。片方は完全なビルドとテストを1時間で完了できますが、もう片方は2～3分かかります。

（辞書に追加します。）

テスト不可能（形容詞）：テストできないソフトウェア。

先日、書籍のサンプルコードをいくつか修正していました。変更を加え、すべてが動作することを確認し、テストを実行して個人リポジトリにコミットしました。その後、別の部分に移って2、3の変更を加えたところ、前の部分で予期せぬテストが失敗しました。自動テストを実行する目的の一部は、予期せぬ失敗を見つけることですが、この書籍のコードは完全に独立した領域を持っています。これは奇妙でした。

探索的テストとは、学習、テスト設計、テスト実行の高速サイクルを重視するテストスタイルです。事前に記述されたテストスクリプトにソフトウェアが準拠していることを検証しようとするのではなく、ソフトウェアの特性を探求し、発見された事項を妥当な動作または障害として分類します。

Given-When-Thenは、テストを表すスタイル、またはその支持者が言うように、例による仕様記述を使用してシステムの動作を指定するスタイルです。Daniel Terhorst-NorthとChris Mattsが振る舞い駆動開発（BDD）の一部として開発したアプローチです。Cucumberなどの多くのテストフレームワークの構造化アプローチとして登場します。4段階テストパターンの言い換えと考えることもできます。

一部のプログラム要素は、本質的にテストが困難、または不可能です。これらの要素のロジックは、バグが発生しやすく、進化させるのが困難です。この問題を軽減するために、テストが困難な要素からできるだけ多くのロジックを移動し、コードベースのよりテストしやすい部分に配置します。テスト不可能なオブジェクトを謙虚にすることで、悪質なバグが潜む可能性を減らすことができます。

インメモリデータベースは、ディスクにアクセスせずにメインメモリで完全に動作するデータベースです。多くの場合、埋め込みデータベースとして動作します。プロセスが開始されるときに作成され、そのプロセス内に埋め込まれて実行され、プロセスが終了するときに破棄されます。

JUnitテストフレームワークの設計上の選択肢の1つ、つまり各テストメソッドの実行ごとに新しいオブジェクトを作成するという決定を取り巻く質問をよく受けます。簡単なblikiエントリを書くだけの価値があります。（ただし、JUnitに関する私の記述が、他の形式のテストが重要ではないと考えているという意味ではないことを指摘する必要があると感じています。多くの有用なテスト活動があり、JUnitとその仲間は多くの活動に役立ちますが、万能の解決策ではありません。テストに関する詳細なブログについては、Brett Pettichord、Brian Marick、James Bachのブログを参照することをお勧めします。また、xUnitテストに関する私の記述が、リファクタリング、ユースケース、フロッシングの重要性を示唆していないと仮定しないでください。）

レガシーシステムを扱う際には、シーム（ソースコードを編集せずにシステムの動作を変更できる場所）を特定して作成することが重要です。シームを見つけたら、それを利用して依存関係を解消してテストを簡素化し、プローブを挿入して可観測性を高め、レガシー置換の一部としてプログラムフローを新しいモジュールにリダイレクトできます。

テスト強化された設計における一般的な問題は、本番環境（および一部のテスト）では本物が存在する一方で、テストモードでサービススタブを作成する方法です。同僚の何人かが彼らのアイデアを共有してくれました。

最近、私がこれまでで最も好きなThoughtworksプロジェクトの1つに時間を費やしました。1998年に開始されたプロジェクトで、当時新しいJ2EEテクノロジーを使用していました。長年にわたり、興味深い歴史があります。EJBから始まり、それを削除し、バンガロールにオフショア化し、シカゴに戻ってきました。多くの人がプロジェクトに出入りし、プロジェクトのヘッドカウントは6から60の間で変化しました。全体として、このプロジェクトには300人年以上の努力が費やされており、約10万行のコードになっています。

オブジェクトマザーとは、テストで使用される例オブジェクトの作成を支援するためにテストで使用される一種のクラスです。

ウェブページに対してテストを作成する場合、リンクをクリックしたり、表示されている内容を確認するために、そのウェブページ内の要素を参照する必要があります。ただし、HTML要素を直接操作するテストを作成すると、UIの変更に対してテストが壊れやすくなります。ページオブジェクトは、HTMLページまたはフラグメントをアプリケーション固有のAPIでラップし、HTMLを掘り下げることなくページ要素を操作できるようにします。

TestDoubleを使用する古典的なケースの1つは、リモートサービスを呼び出す場合です。リモートサービスは通常遅く、信頼性が低いことが多いため、ダブルを使用すると、テストを高速化し、より安定させることができます。

自己テストコードとは、リファクタリングで、機能ソフトウェアと同時に包括的な自動テストを作成する手法として使用した名前です。うまく行けば、これにより、テストを実行する単一のコマンドを呼び出すことができ、これらのテストによってコードに隠れているバグが明らかになるという確信を持つことができます。

2002年にXP/Agile Universeのワークショップに参加していたとき、「例による仕様記述」というフレーズが、XPにおけるテストの役割の1つを説明する方法として私に思いつきました。

開発チームの作業に関する話を聞いていると、静的に保持されているものに対する嫌悪感が共通のテーマとなっています。通常、静的イニシャライザを持つ静的変数に共通のサービスまたはコンポーネントが保持されています。静的（ほとんどの言語で）の大きな問題の1つは、ポリモーフィズムを使用して1つの実装を別のものと置き換えることができないことです。これは、テストの大ファンであるため、多くの問題を引き起こします。そして、うまくテストするためには、サービスをサービススタブに置き換えることが重要です。

合成監視（セマンティック監視とも呼ばれる）は、アプリケーションの自動テストのサブセットを定期的にライブ本番システムに対して実行します。結果は監視サービスにプッシュされ、障害が発生した場合にアラートがトリガーされます。この手法は、自動テストと監視を組み合わせることで、本番環境でのビジネス要件の失敗を検出します。

私のキャリアはフルタイムの執筆に変わりましたが、日々のソフトウェア開発の現実から距離を置くことを心配することがよくあります。他の著名な人物が現実との接触を失うのを見てきたので、同じ運命を恐れています。これに対する私の最大の抵抗源はThoughtworksであり、それは現実の定期的な投与として機能し、私の足を地面につけさせてくれます。

Thoughtworksはまた、現場からのアイデアの源泉としても機能し、同僚が発見して開発した有用な事物について書くことを楽しんでいます。通常、これらは役に立つアイデアであり、私の読者の何人かが使用できることを願っています。今日のトピックはそれほど楽しいトピックではありません。それは問題であり、私たちには答えがありません。

時々、人々が目指すべきテストカバレッジ（コードカバレッジとも呼ばれる）の値を尋ねたり、誇らしげにカバレッジレベルを述べたりしているのを耳にします。そのような声明は要点を見落としています。テストカバレッジは、テストされていないコードベースの部分を見つけるための便利なツールです。テストカバレッジは、テストの質の高さを数値で示すものとしてはほとんど役に立ちません。

Gerard Meszarosは、さまざまなXunitフレームワークを使用するためのパターンをまとめるために書籍に取り組んでいます。彼が遭遇した厄介なものの1つは、スタブ、モック、フェイク、ダミー、および人々がテストのためにシステムの一部をスタブするために使用するその他のもののさまざまな名前です。これに対処するために、彼は独自の語彙を考案しましたが、これはさらに普及する価値があると私は思います。

テスト駆動開発（TDD）とは、テストを作成することでソフトウェア開発をガイドするソフトウェア構築の手法です。これは、1990年代後半にKent Beckによってエクストリームプログラミングの一部として開発されました。本質的には、3つの簡単な手順を繰り返し実行します。

契約による設計（DbC）とテスト駆動開発（TDD）の支持者の間では、長年にわたり、控えめながらも議論が続けられています。ここではその詳細には触れませんが、ダニエル・ジャクソン氏との会話の中で生まれた、両者を融合させるアイデアを紹介します。

テストピラミッドとは、様々な種類の自動テストをどのように使用してバランスの取れたポートフォリオを作成するかについての考え方です。重要な点は、GUIを介して実行される高レベルの広範囲スタックテストよりも、低レベルの単体テストをはるかに多く持つべきということです。

XPデイのセッションに参加しており、オーウェン・ロジャース氏とロブ・スタイルズ氏がXPの単体テストと受け入れテストの違いについて話しています。これによって、受け入れテスト記述用の言語とはどのようなものであるべきかという考えが浮かび上がってきました。

古いメモを調べていたところ、リッチ・ガーザニティ氏から教えてもらったシンプルながらも便利なヒントを見つけました。

XUnitは、ソフトウェア開発者の間で広く知られるようになった多くのテストフレームワークの総称です。この名前は、最初に広く知られるようになったJUnitに由来しています。