テストコードを本番環境に持ち込まないようにする

TL;DR: isTestingや同様のフラグを追加しないでください。

問題😔

• 漏れやすい抽象化
• 非ビジネスコード汚染
• 脆弱なコード
• 一貫性のない行動
• 隠れた依存関係
• デバッグが難しい
• ブールフラグ
• 信頼できないテスト
• 生産依存コード

解決策 😃

1. 動作のIfを削除する
2. 依存性注入を使用する
3. 外部サービスをモデル化する（モック化しない）
4. 個別の構成
5. テストロジックを分離する
6. 明確な行動境界を維持する

リファクタリング⚙️

コンテキスト 💬

isTestingのようなフラグを追加すると、テストコードと本番コードが混在することになります。

これにより、テストでのみアクティブな隠しパスが作成されます。

また、実際の製品コードはカバーされません。

テスト動作を本番環境に配布すると、バグや予期しない動作が発生するリスクがあります。

サンプルコード 📖

間違いです❌

 struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } }

そうだね👉

 trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } }

検出 🔍

• [x]セミオートマチック

この臭いは、 isTesting 、 environment == 'test' 、 DEBUG_MODEなどの条件フラグや、次のような慣用句を探すことで検出できます。

これらは、テストの動作が本番環境のコードに漏れていることを示しています。

タグ 🏷️

• テスト

レベル 🔋

• [x]中級

なぜ全単射が重要なのか 🗺️

テストコードと本番コードを明確に分離する必要があります。

これらを混在させると、現実世界の動作とプログラム間の一対一の全単射が崩れてしまいます。

環境は現実世界のエンティティであるため、 MAPPERで明示的にモデル化する必要があります。

AI世代🤖

AI によって生成されたコードでは、テストのために簡単なハックを使用すると、この臭いがすることがよくあります。

一部のツールでは、適切な設計よりも使いやすさを優先するため、 isTestingなどのフラグを提案します。

AI検出 🥃

AI ツールは、テスト状態に基づいて条件付きロジックにフラグを立てるように構成すると、この臭いを検出できます。

ぜひお試しください！🛠

覚えておいてください：AIアシスタントは多くの間違いを犯します

提案されたプロンプト: IsTestingメソッドを削除し、環境をモデル化して置き換えます

結論 🏁

isTestingフラグの使用は避けてください。

依存性注入を使用して環境をモデル化し、テスト ロジックと本番ロジックを分離します。

関係👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om

免責事項 📘

コードスメルは私の意見です。

クレジット🙏

写真はChristian GertenbachによるUnsplashより

テストフラグを追加すると、本番環境での信頼性が損なわれます。

ウォード・カニンガム

この記事は CodeSmell シリーズの一部です。