😹 🍷 🤜 古いプロジェクトにTDDを実装するためのルール 🤴 👩🏿‍🤝‍👩🏾 🤟

「リポジトリパターンの責任の移動」という記事では、答えるのが非常に難しいいくつかの質問が提起されました。技術的な詳細からの抽出が完全に不可能な場合、リポジトリは必要ですか？リポジトリはスペルを維持するためにどのくらい複雑ですか？これらの質問に対する答えは、システム設計に重点を置いているかどうかによって異なります。おそらく最も難しい質問：リポジトリが必要なのでしょうか？「流体の抽象化」の問題と抽象化のレベルが上がるにつれてコーディングの複雑さが増すため、両方のキャンプを満たすソリューションを見つけることができません。たとえば、レポートインテントの設計では、各フィルターおよび並べ替えに多数のメソッドが作成され、汎用ソリューションでは大きなコーディングオーバーヘッドが発生します。あなたは永遠に続くことができます...

より完全なプレゼンテーションのために、既成のコードやレガシーコードに抽象化を適用する側から抽象化の問題に注目しました。この場合、リポジトリは、高品質で安全なコードを実現するためのツールとしてのみ私たちに興味を持っています。もちろん、TDDプラクティスを適用するために必要なのはこのパターンだけではありません。いくつかの大きなプロジェクトで「味のない食べ物」を食べて、何が機能して何が機能しないのかを見て、TDDプラクティスに従うのに役立ついくつかのルールを思いつきました。 TDDの実装に関する建設的な批判やその他のトリックを聞いてうれしく思います。

まえがき

古いプロジェクトではTDDが不可能であることに気付く人もいるかもしれません。さまざまなタイプの統合テスト（UIテスト、エンドツーエンド）がより適しているという意見があります。古いコードを理解するのは難しすぎます。また、エンコード自体の前にテストを書くと時間の損失につながることもわかります。コードがどのように機能するかわからない場合があります。単体テストは指標ではないことを考慮して、統合テストのみに制限されたいくつかのプロジェクトで作業する必要がありました。同時に、多くのテストが作成され、多数のサービスなどが開始されました。その結果、実際にそれらを作成したのは1人だけでした。

練習中、多くのレガシーコードがあったいくつかの非常に大きなプロジェクトで働くことができました。あるものにはテストがあり、あるものでは単に導入するだけでした。私自身、2つの大きなプロジェクトを集めることができました。そしてどこでも、どういうわけかTDDアプローチを適用しようとしました。 TDDを理解する最初の段階では、テストファースト開発として認識されていました。しかし、遠くなるほど、この単純化された理解と、BDDと呼ばれる現在の見解との違いがより明確に明らかになりました。使用する言語が何であれ、私がルールと呼んだ主要なポイントは同じままです。誰かが良いコードを書くためのルールと他の原則の間に類似点を見つけるかもしれません。

ルール1：ボトムアップ（インサイドアウト）を使用する

このルールは、すでに動作しているプロジェクトに新しいコードを埋め込む際の分析およびソフトウェア設計の方法により関連しています。

新しいプロジェクトを設計するとき、システム全体を提示するのは当然のことです。この時点で、コンポーネントのセットとアーキテクチャの将来の柔軟性の両方を制御します。したがって、便利で最適な方法で相互に統合するモジュールを作成できます。このようなトップダウンアプローチにより、将来のアーキテクチャの優れた先行設計を実行し、必要なガイドを記述し、最終的に必要なものの全体像を把握できます。しばらくすると、プロジェクトはレガシーコードと呼ばれるものに変わります。そして、ここから楽しみが始まります。

多数のモジュールとそれらの間の依存関係を持つ既存のプロジェクトに新しい機能を組み込む必要がある段階では、設計を正しくするためにそれらをすべて頭に入れることは非常に困難です。この問題のもう1つの側面は、このようなタスクを完了するために必要な作業量です。したがって、この場合、下からのアプローチがより効果的です。つまり、最初に必要なタスクを解決する完全なモジュールを作成してから、既存のシステムに埋め込み、必要な変更のみを行います。この場合、次のように、このモジュールの品質を保証できます。機能の完全なユニットを表します。

アプローチでは、すべてがそれほど単純ではないことに注意してください。たとえば、古いシステムで新しい機能を設計する場合、willを使用せず、両方のアプローチを使用します。最初の分析では、システムを評価してから、モジュールレベルまで下げてから実装し、システム全体のレベルに戻す必要があります。私の意見では、ここでの主なことは、特定のツールとして、新しいモジュールが完全に機能し、独立していることを忘れないことです。このアプローチに固執すればするほど、古いコードに加えられる変更は少なくなります。

ルール2：変更されたコードのみをテストする

古いプロジェクトで作業する場合、メソッド/クラスの考えられるすべてのシナリオのテストを記述する必要はまったくありません。さらに、いくつかのシナリオをまったく知らないかもしれません。それらの多くがあります。プロジェクトはすでに実稼働中です。クライアントは満足しているので、リラックスできます。一般的な場合、そのようなシステムでは、変更のみが問題を引き起こします。したがって、それらのみをテストする必要があります。

例

選択したアイテムのバスケットを作成してデータベースに保存するオンラインストアモジュールがあります。特定の実装は気にしません。実行方法、実行方法-これはレガシーコードです。次に、ここで新しい動作を導入する必要があります。バスケットのコストが1000ドルを超えた場合に会計部門に通知を送信します。これが私たちが見るコードです。変更を実装する方法は？

public class EuropeShop : Shop { public override void CreateSale() { var items = LoadSelectedItemsFromDb(); var taxes = new EuropeTaxes(); var saleItems = items.Select(item => taxes.ApplyTaxes(item)).ToList(); var cart = new Cart(); cart.Add(saleItems); taxes.ApplyTaxes(cart); SaveToDb(cart); } }

最初のルールによれば、変更は最小限と原子でなければなりません。データのダウンロードや、税金の計算やデータベースへの保存には興味がありません。しかし、すでに計算されたバスケットに興味があります。必要なことを行うモジュールがあれば、必要なタスクを実行します。したがって、そうします。

 public class EuropeShop : Shop { public override void CreateSale() { var items = LoadSelectedItemsFromDb(); var taxes = new EuropeTaxes(); var saleItems = items.Select(item => taxes.ApplyTaxes(item)).ToList(); var cart = new Cart(); cart.Add(saleItems); taxes.ApplyTaxes(cart); // NEW FEATURE new EuropeShopNotifier().Send(cart); SaveToDb(cart); } }

そのような通知機能はそれ自体で動作し、テストすることができ、古いコードに加えられた変更は最小限です。これはまさに、2番目のルールが言うことです。

ルール3：要件のみのテスト

ユニットテストを必要とするシナリオの数を掘り下げないために、実際にはモジュールから何が必要かを考えてください。モジュール要件として表すことができる最小限の条件セットについて最初に記述してください。新しいセットを追加するときの最小セットは1つで、モジュールの動作はほとんど変更されず、削除するとモジュールは動作しなくなります。 BDDアプローチは、脳を正しい軌道に乗せるのに非常に優れています。

また、モジュールのクライアントである他のクラスがモジュールと対話する方法を想像してください。彼らはあなたのユニットをカスタマイズするには、コードの10行を記述する必要がありますか？簡単には、システムの部品間の通信、良くなります。したがって、特定の原因となっているモジュールを古いコードから分離することをお勧めします。その後、SOLIDの助けに来ます。

例

今度はそれがすべてのようにコードを助け、私たちの上に書かれた方法を見てみましょう。まず、バスケットの作成に間接的にのみ関連するすべてのモジュールを選択します。これは、モジュールの責任を割り当てる方法です。

 public class EuropeShop : Shop { public override void CreateSale() { // 1) load from DB var items = LoadSelectedItemsFromDb(); // 2) Tax-object creates SaleItem and // 4) goes through items and apply taxes var taxes = new EuropeTaxes(); var saleItems = items.Select(item => taxes.ApplyTaxes(item)).ToList(); // 3) creates a cart and 4) applies taxes var cart = new Cart(); cart.Add(saleItems); taxes.ApplyTaxes(cart); new EuropeShopNotifier().Send(cart); // 4) store to DB SaveToDb(cart); } }

そして、それらを区別することができます。もちろん、一度にこのような変更を行うことは、大規模なシステムでは不可能ですが、徐々に行うことができます。たとえば、変更が税モジュールに関係する場合、システムの他の部分からの依存関係を簡素化できます。これは、彼への強い依存関係を取り除き、将来的には自給自足のツールとして使用するのに役立ちます。

 public class EuropeShop : Shop { public override void CreateSale() { // 1) extracted to a repository var itemsRepository = new ItemsRepository(); var items = itemsRepository.LoadSelectedItems(); // 2) extracted to a mapper var saleItems = items.ConvertToSaleItems(); // 3) still creates a cart var cart = new Cart(); cart.Add(saleItems); // 4) all routines to apply taxes are extracted to the Tax-object new EuropeTaxes().ApplyTaxes(cart); new EuropeShopNotifier().Send(cart); // 5) extracted to a repository itemsRepository.Save(cart); } }

テストに関しては、これらのシナリオでうまくいくことができます。これまでのところ、それらの実装には興味がありません。

 public class EuropeTaxesTests { public void Should_not_fail_for_null() { } public void Should_apply_taxes_to_items() { } public void Should_apply_taxes_to_whole_cart() { } public void Should_apply_taxes_to_whole_cart_and_change_items() { } } public class EuropeShopNotifierTests { public void Should_not_send_when_less_or_equals_to_1000() { } public void Should_send_when_greater_than_1000() { } public void Should_raise_exception_when_cannot_send() { } }

ルール4：テスト済みコードのみを追加

上記で書いたように、古いコードへの変更を最小限に抑える必要があります。これを行うには、古いコードと新しい/変更されたコードを分離できます。新しいコードは、単体テストで動作を確認できるメソッドに区別できます。このアプローチは、関連するリスクを軽減するのに役立ちます。「レガシーコードを効果的に使用する」で説明されている2つの手法があります（以下の本へのリンク）。

スプラウトメソッド/クラス-この手法により、古いコードに新しいコードを非常に安全に埋め込むことができます。通知機能を追加した方法は、このアプローチの例です。

ラップ方法-もう少し複雑ですが、本質は同じです。常に適切であるとは限りませんが、新しいコードが古いコードの前/後に呼び出される場合のみです。責任を割り当てる際に、ApplyTaxesメソッドへの2つの呼び出しが1つの呼び出しに置き換えられました。これを行うには、作業のロジックがあまり壊れずに確認できるように、2番目のメソッドを変更する必要がありました。クラスが変更に見えました。

 public class EuropeTaxes : Taxes { internal override SaleItem ApplyTaxes(Item item) { var saleItem = new SaleItem(item) { SalePrice = item.Price*1.2m }; return saleItem; } internal override void ApplyTaxes(Cart cart) { if (cart.TotalSalePrice <= 300m) return; var exclusion = 30m/cart.SaleItems.Count; foreach (var item in cart.SaleItems) if (item.SalePrice - exclusion > 100m) item.SalePrice -= exclusion; } }

そして、これは後です。バスケットの要素を操作するロジックは少し変更されましたが、一般的にはすべてが同じままです。この場合、古いメソッドは最初に新しいApplyToItemsを呼び出し、次に以前のバージョンを呼び出します。これがこのテクニックの本質です。

 public class EuropeTaxes : Taxes { internal override void ApplyTaxes(Cart cart) { ApplyToItems(cart); ApplyToCart(cart); } private void ApplyToItems(Cart cart) { foreach (var item in cart.SaleItems) item.SalePrice = item.Price*1.2m; } private void ApplyToCart(Cart cart) { if (cart.TotalSalePrice <= 300m) return; var exclusion = 30m / cart.SaleItems.Count; foreach (var item in cart.SaleItems) if (item.SalePrice - exclusion > 100m) item.SalePrice -= exclusion; } }

ルール5：隠された依存関係の「破壊」

このルールは、古いコードの最大の悪に関するものです。あるBOのメソッド内でnew演算子を使用して、他のBO、リポジトリ、または他の複雑なオブジェクトを作成することです。なぜこれが悪いのですか？最も簡単な説明：これにより、システムの各部分が高度に接続され、一貫性が低下します。さらに短く：「低結合、高凝集」の原則に違反します。反対側から見ると、そのようなコードは非常に難しく、独立した独立したツールに分離できません。そのような隠れた依存関係を一度に取り除くことは非常に時間がかかります。しかし、これは徐々に行うことができます。

最初に、すべての依存関係の初期化をコンストラクターに転送する必要があります。特に、これは新しい演算子とクラスの作成に適用されます。クラスのインスタンスを受け取るためのServiceLocatorがある場合は、コンストラクターから削除して、必要なすべてのインターフェイスを取得できるようにする必要があります。

第二に、外部BO /リポジトリのインスタンスを格納する変数には、抽象型、できればインターフェースが必要です。より良いインターフェース、など開発者の手をもっと解きます。最終的に、これによりモジュールからアトミックなインストゥルメントを作成できるようになります。

第三には、偉大な方法で、シートを放置しないでください。これは、メソッドがその名前で示されている以上のことを行っていることを明確に示しています。そしてこれは、デメテルの法則であるソリッドの違反の可能性を示しています。 ~~論理と地球秩序と同様に。~~

例

上記のバスケットが変更された後、バスケットを作成するコードを見てみましょう。バスケットを作成するコードブロックのみが変更されません。残りは外部クラスに割り当てられ、任意の実装で置き換えることができます。 EuropeShopクラスは、コンストラクターで明示的に表される特定のものを必要とするアトミックツールの形式を取ります。コードが理解しやすくなります。

 public class EuropeShop : Shop { private readonly IItemsRepository _itemsRepository; private readonly Taxes.Taxes _europeTaxes; private readonly INotifier _europeShopNotifier; public EuropeShop() { _itemsRepository = new ItemsRepository(); _europeTaxes = new EuropeTaxes(); _europeShopNotifier = new EuropeShopNotifier(); } public override void CreateSale() { var items = _itemsRepository.LoadSelectedItems(); var saleItems = items.ConvertToSaleItems(); var cart = new Cart(); cart.Add(saleItems); _europeTaxes.ApplyTaxes(cart); _europeShopNotifier.Send(cart); _itemsRepository.Save(cart); } }

ルール6：小さな大きなテスト、より良いです

大規模なテストは、ユーザースクリプトをテストしようとするさまざまな統合テストです。確かに、それらは重要ですが、コードの後ろにあるIFのロジックをチェックするのは非常に高価です。その結果、アミュレットで覆われた特別なスーツを着た1人の開発者のみがそこで何かを変更できます。このようなテストを作成するには、機能自体を作成するのと同じくらいの時間が必要です。それらをサポートすることは、変更するのが怖いだけの別のレガシーコードです。ただし、これらは単なるテストです！

ないように、あなたの穴と、彼らはテストが必要とされているどのようなものを共有しなければならない可能fakapeについてのそれらに警告し、明確にこの部門に付着するという希望をテストするために、統合テストをしてみてくださいマウントデザイナーレーキ上のステップへ。統合テストが必要な場合は、肯定的および否定的な相互作用シナリオを含む、最小限のテストセットを作成します。アルゴリズムを確認する必要がある場合は、単体テストを作成し、最小限のセットに制限してください。

ルール7：プライベートメソッドをテストしない

突然プライベートメソッドをテストしたい場合、どうやら松葉杖に憧れたようです。一部の人はそれで何の問題も見ていません。しかし、「ウィッシュリスト」の理由を見てみましょう。プライベートメソッドが複雑すぎるか、パブリックメソッドから呼び出されないコードが含まれている可能性があります。あなたが考えることができる他の理由は、「悪い」コードやデザインの特徴であると判明するでしょう。ほとんどの場合、プライベートメソッドのコードの一部を別のメソッド/クラスに割り当てる必要があります。最初のSOLID原則に違反していないか確認しますか？これが、これを行う価値がない最初の理由です。 2番目は、この方法で、モジュール全体の動作ではなく、それがどのように行われるかを確認することです。内部実装は、モジュールの動作に関係なく異なる場合があります。したがって、この場合、脆弱なテストが行われ、必要以上にサポートに時間がかかります。

プライベートメソッドをテストする必要を避けるために、クラスを、何も知らないアトミックツールのセットと考えてください。テストしている動作を期待します。このビューは、アセンブリクラスにも有効です。クライアントが（他のアセンブリから）利用できるクラスはパブリックになり、内部作業を実行するクラスはプライベートになります。ただし、メソッドとは異なります。内部クラスは複雑になる可能性があるため、内部クラスを作成してテストすることもできます。

例

たとえば、EuropeTaxesクラスのプライベートメソッドで1つの条件をテストするために、このメソッドのテストを作成しません。私は税金が特定の方法で適用されることを期待するので、テストにはそれが反映されます。テスト自体では、結果がどうなるかをペンで数え、それを標準として取り、クラスから同じ結果を期待しました。

 public class EuropeTaxes : Taxes { // code skipped private void ApplyToCart(Cart cart) { if (cart.TotalSalePrice <= 300m) return; // <<< I WANT TO TEST THIS CONDIFTION var exclusion = 30m / cart.SaleItems.Count; foreach (var item in cart.SaleItems) if (item.SalePrice - exclusion > 100m) item.SalePrice -= exclusion; } } // test suite public class EuropeTaxesTests { // code skipped [Fact] public void Should_apply_taxes_to_cart_greater_300() { #region arrange // list of items which will create a cart greater 300 var saleItems = new List<Item>(new[]{new Item {Price = 83.34m}, new Item {Price = 83.34m},new Item {Price = 83.34m}}) .ConvertToSaleItems(); var cart = new Cart(); cart.Add(saleItems); const decimal expected = 83.34m*3*1.2m; #endregion // act new EuropeTaxes().ApplyTaxes(cart); // assert Assert.Equal(expected, cart.TotalSalePrice); } }

8ルール：アルゴリズム技術をテストしないでください。

ここでは、ルールの名前の選択に失敗しましたが、より良い名前はまだ出ていません。「Moquists」（テストに濡れる人）の中には、特定のメソッドへの呼び出し回数をチェックしたり、呼び出し自体を検証したりする人がいます。つまり、メソッドの内部動作をチェックします。これはプライベートテストと同じくらい悪いです。唯一の違いは、このようなチェックの適用レベルです。このアプローチでも、多くの脆弱なテストが行われるため、TDDが通常のように認識されない場合があります。

ルール9：テストなしでレガシーコードを変更しないでください

これが最も重要なルールです。なぜならチームがそのような道をたどるという願望を反映しています。この方向に移動したいという欲求がなければ、上記で述べたすべてのことは特別な意味を持ちません。なぜなら開発者がTDDの使用を望まない場合（その意味を理解していない、利点が分からないなど）、真の利点は、それがどれほど困難で効果がないかを絶えず議論することによって損なわれます。

TDDを適用する場合は、チームで話し合い、[完了の定義]に追加して適用してください。新しいものすべてと同様に、最初は難しいでしょう。他のアートと同様に、TDDには絶え間ない練習が必要であり、学ぶにつれて喜びがもたらされます。徐々に、書かれた単体テストが多くなり、システムの健全性を感じ始め、最初の段階で要件を説明するコードの書きやすさを評価し始めます。 MicrosoftとIBMで実際の大規模プロジェクトで実施されたTDD研究があり、実稼働システムのバグが40％から80％に減少したことが示されています。（以下のリンクを参照）。

古いプロジェクトにTDDを実装するためのルール