1

テストに関する簡単な社内講義を行います。いわゆるテストバックドア パターンが悪魔と見なされる理由の良い例を教えてください。私はそれがアンチパターンであると確信していますが、同僚にもこれを指摘したいと思います.

testbackdoor が頭痛の種になる可能性があると感じていますが、その理由を説明することはできません。

4

2 に答える 2

0

Back Door Manipulationは、テストとSUTによって使用されるフィクスチャとの間の結合を作成します。つまり、フィクスチャの実装が変更された場合、テストの更新も必要になる場合があります。ただし、SUT をリファクタリングする場合、リファクタリングによって SUT の動作が変更されていないことをテストで確認できるはずです。リファクタリングによって、テストの変更が必要な方法でフィクスチャが変更された場合、これを行うことはできません。

たとえば、プライベート フィールドの状態を維持するクラスをテストしていて、バック ドア操作を使用してこれらのフィールドを設定用に変更し、検証用にフィールドの値をチェックしたとします。次に、クラスをリファクタリングして (たとえば)、フィールドの冗長性を取り除き、フィールドでより適切な型を使用します。テストが壊れており、クラスの動作が変更されていないことを確認する方法がありません。新しいフィールドを使用するようにテストを変更することはできますが、テストがまだ同じ動作をテストしていること、および SUT とテストにバグが導入されていないことをどのようにして確認できますか?

于 2013-11-12T14:45:14.783 に答える
0

バックドア操作パターンを単体テストで使用すると、外部依存関係への継続的な依存が可能になり、促進されます。依存関係の逆転の原則の違反を可能にします。これにより、グローバル変数などの危険な行為が許可されます。また、テストと開発の作業を外部データベースに結合します。

ユニットテストとは？

単体テストは、システムの機能ではなく、コードの 1 つの単位をテストするテストです。メソッドを介して1つのパスをテストしています。データベースをテストしようとするべきではありません。コードの他の機能をテストしようとするべきではありません。画面に表示される少量のコードのみをテストする必要があります。

グローバルは悪いです。

グローバル変数とは何か、なぜそれが問題になるのかを考えてみてください。それらは、他の誰かが変更できる、あなたが依存している隠れた状態です。プログラムの他の場所で誰かがその値を変更すると、コードは異なる動作をします。グローバルはインターフェイスに表示されないため、コードを再利用したい人はグローバルの重要性を知りません。グローバルはカプセル化に違反しているため、コードはモジュール化されていません。グローバルは、コードを理解しにくく、再利用しにくくし、テストしにくくし、バグを引き起こします。

バックドア操作を使用しても、グローバルを設定し、テストを実行してからグローバルをチェックする単体テストを作成できます。このテストにより、グローバルの存続が可能になります。しかし、コードの他の部分がいつでもグローバルを変更する可能性があるため、テストは実際にはコードについて何も証明していません。代わりに、コードをリファクタリングして、依存関係の挿入パターンに従って、インターフェイスで変数を渡す必要があります。そうすれば、コードを再利用しようとする人は誰でも、そのデータを提供する必要があることがわかります。コードを再利用しようとする人に隠し事は何もありません。

データベースはユニットよりも大きくなります。

データベースへの依存が単体テストにとって良くない理由を考えてみてください。テストを実行するには、テスト システムでデータベースを使用できる必要があります。開発者は、テストを実行して開発するためにデータベースを利用できるようにする必要があります。データベースへのネットワークが稼働している必要があります。データベース サーバーには、適切なデータベース、適切なスキーマ、適切なユーザー、適切なストアド プロシージャ、適切なテーブル、適切な行、および適切な値が存在する必要があります。ユーザーとテスト サーバーは、ネットワーク、サーバー、およびデータベースにアクセスするための有効な資格情報とパスワードを持っている必要があります。開発者のデータベースとテスト データベースは、どちらも同じ SQL の方言を話す必要があります。アプリケーションのアクセスを読み取り専用にする必要がある場合でも、テストをセットアップするには書き込みアクセスが必要です。共有データベースでのテストは、データベースを使用してコンテンツを変更する他のユーザーによって妨害される可能性があります。開発者のワークステーションとテスト サーバーには、正しいデータ アクセス オブジェクトがインストールされている必要があります。そして、それらのいずれかが問題になると、テストが停止し、テスト駆動開発が停止します。

これらの依存関係のいずれも、コードまたは運用環境の動作について何も証明しません。そのため、セットアップと保守に費用がかかり、実際のコードがテストされているという証拠には何も追加されず、コーディングが停止する可能性があり、すべてのテストと開発には常に可用性が必要です。

代わりに、コードは依存性注入を使用してデータベース接続 (または必要なデータなど) を渡す必要があります。単体テスト ハーネスは、テスト条件を確立するために必要なデータを正確に返す、フェイクまたはモックのデータベース接続を挿入できます。適切に記述されていれば、自動化された単体テスト システムは、データベースにアクセスしなくても完全に実行されます。おまけとして、データベースへのアクセスを待機しないため、モック オブジェクトからデータを取得するときにテストが桁違いに速く実行されます。各ビルドを実行する単体テストが 50,000 件ある場合、これは重要です。

バックドア操作が適切なのはいつですか?

バックドア操作のアイデアは、自動化されたシステム テストと自動化された統合テストに最適です。ユーザーレベルの関数が正しいデータの存在下で機能することを証明できます。ユーザーレベルの関数がデータベース内のデータを適切に操作していることを証明できます。

多くの場合、バック ドア操作は、レガシー コードの単体テストを作成する最も効果的な方法です。レガシ コードは単体テストのないコードであり、既存の多くのプロジェクトで現実のものとなっています。バックドア操作は、進行中の変更が存在する場合でも、開発者がレガシー コードの継続的な安定性を保証するテストを作成するのに役立ちます。保存されているのは良いコードではないかもしれませんが、しばらくの間、まだ一緒に暮らさなければならないコードです。

しかし、新しいコードのテスト駆動型開発中にユニット テスト内で実行する場合、バック ドア操作を使用すると、ユニット テストよりも大規模なテストが促進されます。テスト駆動開発を停止させる可能性があるため、自動化された単体テストには適していません。また、非モジュラー コードが可能になるため、コードの品質と再利用に悪影響を及ぼします。

于 2013-11-19T20:52:52.107 に答える