ソフトウェアの断片を独立したレイヤーに分割し、動的検出と依存性注入を使用してそれらを分離する努力が増えるにつれて、システム内のどの「レイヤー」が「アプリケーション」のシステム全体の障害に寄与しているかを判断することが難しくなっています。
単体テストは、レイヤーを構成するすべての「モジュール」が期待どおりに機能していることを確認するのに役立ちます。ただし、単体テストは、スタブやモックなどの手法を使用して各「モジュール」を分離するように記述されています。
以下の単純な例を考えてみましょう。
L1。データベース -> L2。データベース層 -> L3。Windows サービス -> L4。クライアント アプリケーション
たとえば、データベース エンジンがダウンしている場合、システムは正常に動作しません。データベース エンジンが本当にダウンしているのか、それともデータベース レイヤー (L2) コードにバグがあるのかを判断するのは困難です。確認するには、何らかのデータベース管理ツールを起動して、データベース エンジンが実行されているかどうかを確認する必要があります。
私たちが達成しようとしているのは、システムに「何か問題がある」ときにいつでも起動できる開発者ツールです。このツールは、各レイヤーに「整合性」または「診断」データを「照会」します。このツールは、ソフトウェア層とその「整合性ステータス」のリストを提供します。これですぐに、レイヤ X が問題の原因である (つまり、データベース エンジンがダウンしている) と言うことができます。
もちろん、各レイヤーは、ツールによって照会できる独自の「診断方法」を提供する責任があります。
ここで達成しようとしているのは、ある種の「統合テスト」フレームワーク、または実行時に使用できる同様のものです (単体テストのようなコンパイル/ビルド時間ではありません)。インスピレーションは、車のような独自の「オンボード診断」を備えた物理デバイスから生まれました。ソフトウェアの世界での良い例は、コンピュータの電源を入れるたびに実行されるパワーオン セルフ テストです。
このようなことを見たり聞いたりしたことがある人はいますか？提案や指針はきっと大いに役立ちます！