👃🏻 🙅🏽 ✌️ 分離された単体テストを使用して、システム設計を制御下に保つ 🎉 🏬 🌸

同意して、既製のコードの束を捨てたい状況は非常に迷惑です。この記事では、 Andrei Kolomenskyと一緒に、この原因を特定し、最大の生産性のポイントでシステムがどのように見えるべきかを調べる方法を説明します。どのアプローチが不十分な綿密な設計の悪循環に私たちを引き込み、最終的に高品質のシステム設計につながり、欠陥のリスクを減らすテスト可能なシステムを得ることができるかを分析しましょう。

今日は

複雑な依存関係をテストする方法は？
優れたテストカバレッジを実現する方法
テストは設計にどのように影響しますか？
データベースに多くのロジックがある場合はどうしますか？
デザインと非デザインの間のトレードオフをどのように打ち消すか。

講演者について： Andrei Kolomensky- OnAgileの Agile Coachは10年以上コードを書き、支払いシステムなどの複雑なドメインモデルと、保存する必要がある複雑なレガシーコードの開発と、それらの作業の生産性を回復する必要のある両方の開発に取り組みました。

仕事中ずっと、次の問題に気づきました。プロジェクトを開始するとき、または既にプロジェクトに取り組んでいるときは、常に一定の速度で移動することを期待しています（タイトルの写真のように）。しかし、現実には、現実は私たちに同意しません。

私たち全員が非常に頻繁に野生の非生産的になります。最初は、プログラマとして私たちが多くの機能を実装し、最終的にはほとんど機能を提供していないと文句を言うことをビジネスは喜んでいます。その結果、ほぼ疑問符が置かれている中間ゾーンでは、すべてを書き直したり、主要なリファクタリングを実行したいという強い要望があります。

コードを破棄したい状況は、私を非常に困らせます。これは私に非常に近いトピックです。私は1年半にわたって銀行ウォレットソリューションを開発しました。この間ずっと生産に行かず、ほとんどすべての準備が整った時点で、銀行は免許を取り消されました。

ビジネスは、コードを削除せずに別の製品を作成することを決定しました。ウォレットの決定ではなく、支払いアグリゲーターです。対象分野は非常に似ています。ユーザーからお金を受け取り、手数料を取り去り、店舗にお金を渡します。

意味の近いドメインであっても、このようなピボットを作成できなかったため、すべてのコードを破棄しました。これにはいくつかの理由がありました。

私たちのコードは難しすぎました。剛性は、システムが変更に抵抗することを示します。システムを変更するには、多くのコンポーネントに触れる必要があります。
私たちのシステムは脆弱でした。これは、一見小さな変更を加えたときに、システムがさまざまな場所で故障する傾向です。
私たちのシステムは耐えられない不動でした。これがシステムの品質です。つまり、システム間でコードを再利用することはできません。より正確には、できますが、抽出のコストは最初からコードを書くコストよりも高くなります。
私たちのシステムには、不必要な複製（ 不必要な繰り返し ）と過度の複雑さ（ 不必要な複雑さ ）が含まれていました。
私たちはそれに焦点を合わせましたが、意図の表現の明瞭さ（ 不透明度 ）はかなり低かったです。プログラマーのよくある間違いは、新製品を発売し、長期間本番稼働しない場合、将来のために準備をしておくことです。このため、システムのスタブ部分をどのように配置する必要があるか、それらの要素をどのように配置するか、どのような動作と依存関係を持たせるべきかを理解していませんでした。上記の機能障害は、システムの残りの部分の明瞭さを妨げました。
最後の粘度パラメーターは別に作成しました。これは品質の属性であり、システムが高品質のアーキテクチャソリューションの使用に抵抗する度合いを示します。テストに1時間かかり、TDDについて何も話せない場合、これは巨大な粘度指数を持つシステムです。

質問：生産性を最大限に高めるために、システムがどのように見えるべきかをどのように知るのですか

捨てたコードはテストでカバーされました。私たちはその品質をリファクタリングしましたが、結果としてほとんどすべてを捨てました。

システムからフィードバックを得るには、システムを設計する方法を理解するのに役立つ何らかのツールが必要です。頭の中にある知識だけでは、システムが一般的にどのように見えるべきかをいつでも知るには十分ではないかもしれません。

単体テストは、システムからフィードバックを受け取るための主要なツールです。

単体テストを作成するとき、少なくともシステムの正確性とテスト容易性の小さな品質を保証できます。

1つのテストを見てみましょう。

真空のBuyProductsActionに例があります-一部の製品を購入します。このテストについて質問がありますが、その主なものは、このテストからシステムの品質について何を学ぶことができますか？ほとんど何もありません：入力パラメーターを反復処理し、アサーションを追加し、何らかの方法で追加のチェックを提供できます。さらに、製品とユーザーの特性が非常に多く、データベース内のパラメーターが多すぎるため、多くを確認する必要があります。

ここではシステム設計について何も学びません。これが、すべてのコードを投げた理由です。テストから学んだことにより、システムの設計を合理的に改善することができなかったからです。

BuyProductsActionは内部で何ができますか？注文を作成し、通知を送信し、アカウントからお金を償却し、利子ボーナスを獲得します-それは内部で多くのことができます。

統合テストとは何ですか？

ユニットテストの概念は、あまりにも曖昧であり、誰もが独自の方法でそれを理解しているため、今はそのままにします。

統合テストとは、パスまたはドロップするテストです

自明でない動作の複数のユニットに依存します。

つまり、このテストが失敗した理由を具体的に示すことはできません。エラーがある場所、テスト領域の一部のコンポーネントが落ち、特定の場所ではないことがわかると、このテストは統合されます。

分離テストは、自明ではない1つのユニットのテストです。

行動、これの通過または落下はこれだけに依存する

動作。

実際、これは1つのメソッドまたはシステムの一部に対するテストであり、重要な動作の残りはmokiに置き換えられます。

BuyProductsActionメソッドのテストを分離しようとすると、すべてが完全にテストされるのではなく、runメソッドが排他的に実行され、それに含まれる依存関係の自明でない動作から分離される場合に発生すると仮定します。

最も可能性が高いのは、同様のテストで記述されたシステムがシステム設計にそれほど大きな影響を与えないため、これを行うことができず、分離されたテストをすぐに記述できるためです。これを行うことができたとしても、ほとんどの場合ゴミがあります。

入力パラメーターが渡されるAnaliticsComponentのようなものがあると言うことから始めます。このことをサービスロケーターに入れます。動作を設定する他のコンポーネントがいくつかあります。

読む必要のないコンポーネントもあります-それらは単にボリュームを明確にするためのものです。

分離テストで明示的に規定する場合、分離テストで見られる依存関係の数は、会社で分離テストを書く習慣がない場合、通常非常に多くなります。孤立したテストを作成できたとしても、状況は通常次のようになります。

システムをテスト可能な状態にリファクタリングするときに最初にすることは、依存関係をクラスにプッシュし、明示的にコンストラクターに注入することです。

このテストを見たときに尋ねられる主な質問は、このテストからシステムの品質について何を学べますか？

私は、単独責任の原則が明らかに違反していると思います。ここでは、「理解可能性」に関する主観的な言説から抜け出すことはできません。このテストは筆者にとって読み書きが難しいことがわかります。このクラスに変更を加えると、このテストは常に低下することがわかります。この架空のテストをプレゼンテーション用に準備することは私にとって困難でした。

この生産コードを書いたら、私たちはただ夢中になるでしょう。

システム設計の品質とその合理的なリファクタリングを改善するために、孤立したテストを使用します。

彼らは私のシステムについて最も完全なフィードバックを提供します。

統合されたテストによって、システムの一部が入力パラメーターの一部で正しく機能するという基本的な理解しか得られない場合、分離テストにより、システムで何が起こっているかを明確に確認できます。 孤立したテストを作成する際の不快感の程度は、システムのテスト容易性の程度に対応します。

腐敗システム

すべての単体テストに合格しましたが、QA部門が何らかの欠陥を発見しました。問題は2つのコンポーネントの接合部にあることを理解し、統合テストを作成することを決定しました。これは、より簡単であり、実際の作業を確認する必要があるためです。

ちなみに、バグという言葉の使用はお勧めしません。これはハエです

業界の夜明けにサーバーに飛び込みました。 ITからのバグの例

開発は、SkypeからSQLクエリをコピーしてコードに貼り付けたときに行われますが、Skypeがスペースの代わりに挿入されるため、そこでは機能しません

切り離せない空間。これが起こるとき-これはバグです。残りの

ケース、私は単語の欠陥を使用することを好むので、

プログラムの不正な振る舞いは偶然ではなく、プログラマーの直接の責任です。より強力な言葉遣いの欠陥

責任を取り除く「バグ」よりも。具体的な証拠はありませんが、

チームは、単に認識と責任を高めることで品質を向上させるために、単に単語のバグから単語の欠陥に切り替えたという事実のために管理しました。

統合テストを作成したため、システムの設計への影響は少なくなります。統合テストを作成するとき、さまざまな方法で実装を作成できます：一連の依存関係を挿入し、システムの動作を変更する静的メソッドを呼び出し、サービスロケーターから呼び出しだけのベールを呼び出します-絶対に、完全に自由です。

したがって、簡単な生活から、システムの設計はそれほど慎重ではありません。私たちはシステムがどのように配置されるかを気にしません-私たち自身の内面の美しさの感覚だけでシステムを見て、どのように最高かを考えます。しかし、テストからのプレッシャーはありません。

これは、システムのテスト容易性が低下するという事実につながり、今では小さな分離テストを書くことができません。少なくとも、たとえ書くことができたとしても、それはより困難になっています。

この点で、システムのテストが難しくなるため、欠陥のリスクが高くなります。高品質の小規模な単体テストを作成する時間が少なくなりました。

孤立したテストを書くのは難しいので、私たちは円に戻り、最終的に統合されたテストのみを書くことにします。その結果、システムの設計に何も影響を与えない状況になります。私たちだけが-私たちが望むように、私たちは書きます。

代替オプション。

同じ状況-彼らは単体テストに合格しましたが、欠陥がありました。小さな分離テストを作成するとどうなりますか。システムがこれらの小さな孤立したテストの記述を妨げるという事実に関して、多くの問題に直面します。

私たちの生活を楽にし、そこで何が起こっているのかを理解できるようにこれらの分離されたテストを質の高い方法で書き始めるために、システムをより慎重に設計し始め、巨大なテストを書く必要がなくなりました。

テストを小さくするためには、システムの品質を高め、唯一の責任の原則と一致させるために、一生懸命努力する必要があります。これにより、システムのテスト容易性が向上します。分離された単体テストを記述しやすくするために、システムを可能な限りテスト可能にするようにします。

その結果、テスト可能なシステムでは、小さな孤立した単体テストを作成する時間が増え、高品質のシステム設計が可能になり、欠陥のリスクが軽減されます。「実際の作業」が行われていないという事実はどうですか？このトピックを開く前に、もう1点触れておきたいと思います。私のポイントは：

高い生産性を継続的に維持することのみが可能です。

規律テスト駆動開発の実践。

反対の意見も非常に一般的ですが（たとえば、このトピックに関するビデオ）。

テスト駆動開発

テスト駆動開発は専門分野です。規律とは、それを適用することによって自分自身に課す制限を意味します。これはRed-Green-Refactoringではなく、一連の特定のルールです。

落下単体テストがない限り、製品コードを書くことはできません。
単体テストコードを、ドロップするのに十分な数以上記述することはできません。コンパイルエラーはすべて落ちます。コンパイルエラーが発生しても、クラッシュするとすぐに単体テストの作成をすぐに停止します。
1つの落下ユニットテストに合格するのに十分な量を超える本番コードを記述することはできません。また、特定の落下ユニットテストに適用されない本番コードを記述することはできません。

テストを書くだけでなく、実装はRed-Green-Refactoringだけではありません。これらは追加の制限です。これはテスト駆動開発です。これにより、システムを高品質の状態に維持し、長期にわたって可能な限り最高の生産性を維持できます。

レガシーコード

Michaels C. Feathersの定義によると、 レガシーコードは単体テストのないコードです 。すべてがシンプルです。私の実践では、テストの欠如とシステム設計に関する膨大な数の問題の存在、および統合テストの存在とシステム設計の問題とのほぼ同じ依存性の間に直接的な相関関係があることに気付きました。小規模な分離テストが少ないほど、システム設計の問題が多くなります。

テストがない場合、それはレガシーです。

私は他の定義が好きです。それはそれほど正確ではありませんが、現実を反映しています。

レガシーコードとは、変更するのが怖いコードです。

デイブ・トーマスはかつて次のようなことを言っていました。「テストをまったく書かない場合もありますが、すでに高品質のシステムを設計できます。」

まず、彼は膨大な量の単体テストの経験を持っています。第二に、テストなしでこのようなシステムを使用する場合、私にとってこのシステムはレガシーになります。変更を加えることが怖いからです。変更を行うことの恐怖が、コードの劣化の主な理由です。テスト駆動開発の分野は薬です。この規律をコミットして使用すると、コードのすべての行についてフィードバックが得られるため、変更の恐れがなくなります。

ロバート・マーティンは、私たちの職業では、医師に対するヒポクラテスの誓いに似た誓いを立てることを提案しています。単体テストが業界で少なくとも重要である理由を明確に示すためにここにそれをもたらします。そして、最大で、規律としてのテスト駆動開発がプログラマーとして重要です。

プログラマーの誓い

プログラマーの職業の名誉を守り、維持するために、私の能力と判断の及ぶ限りでは、それを約束します。

1.悪意のあるコードを作成しません。

これは、ウイルスだけでなく、当社に損失をもたらすコードにも適用されます。会社の損失を引き起こすコードを書いた場合、これは悪意のあるコードです。

2.私が作成するコードは、常に私の最高の作品です。

動作と構造の両方で、コードに欠陥があることを故意に許可しません。もちろん、振る舞いにおいて、何らかの検証がない場合、その正確性を保証することはできません。構造上、小さな孤立した単体テストがない場合、システムの設計がテスト可能で高品質であることを保証できません。

3.各リリースで、コードのすべての要素が正常に機能することを、迅速かつ信頼性が高く、再現可能な証拠として提供します。

この項目の重要性は、多くの企業が手動テストに費やし、自動化できるものに費やし、同時にコードの品質を改善するために使用し、結果として開発をスピードアップするために使用する金額を見ると特に顕著です。

4.他の人の進行を妨げないように、頻繁に小さなリリースを行います。

迅速に出荷するには、小さなリリースを作成する必要があります。個人的には、テストなしで十分な品質の小さなリリースを作成することはできません。

5.私はあらゆる機会にコードを大胆かつ精力的に改善します。 私はその品質を決して低下させません。

コードをリファクタリングするために、変更することを恐れる必要はありません。私の古いパターンは次のように見えました。システム内の場所と、このシステムに変更を加える2つの方法があります。簡単な方法（「松葉杖」）と深刻なリファクタリングが必要な場合の難しい方法です。

テストがない場合は、何かを壊すことができるため、サブジェクト領域の構造を真剣に変更することはありません。そして、私は何かを壊したくないので、簡単な方法を選択します。

単体テストではこのような問題はありません。テスト駆動開発を実践すれば、まったく問題はありません-私のコードは常に正しいです。何かがそこで壊れると、状況が完全にコントロールされていたため、どこかでめちゃくちゃになったような気がするので、プロとしての苦痛です。個人的には、欠陥の発生は深刻な課題です。

6.私は、自分自身と他者の生産性を可能な限り高く保つために、できる限りのことを行います。 この生産性を低下させるようなことは何もしません

テスト駆動開発は生産性を低下させるか、長期間実践すると生産性が向上すると言われます。実際、生産性を一定レベルに維持します。

私たちの仕事は、より速く動くことではなく、一定の速度で動き、弱い建築ソリューションに関連する損失を確実に取り除くことです。

テスト駆動開発により、これを行うことができます。

7.他の人が私を置き換えることができることを常に確認し、それらを置き換えることができます

他の人のコードを見て、そこにテストがない場合、これは私にとって問題です。そこで何が起こっているのかを理解することはできますが、何かを考慮に入れることができないため、そこで変更を加えるのが怖いです。チームがペアプログラミングと完全なカバレッジを単体テストで実践している場合、お互いを交換してシステムのさまざまな部分で作業することは非常に簡単です。すべてが安全です。

8.私は、正確さと正確さの両方で正直な見積もりをします。 私はそれを守れるという自信がなければ約束をしません

ひどいレガシーがあり、1週間かかると言ってから、悪いコードのある場所を掘り起こすと、今週は3つになります-レガシーコードで非常によくあることです。

9.私は自分の工芸を学ぶことをやめません

少し運動

テスト駆動開発により生産性を最大の一定レベルに保つことができるというステートメントを確認することをお勧めします。あなたの製品で、あなたがうまく設計されていると思うシステムの一部を見つけてみてください。テストはあるかもしれませんが、それらは統合されており、システムのこの部分で小さな孤立した単体テストを書いてみてください。次に、私が個人的にどのようにそれらを書くかを示します。

あなたが経験する不快感の程度は、このシステムの品質の程度に対応します。 小規模な独立したテストにより、システムの設計がどれほど適切であるか、または不十分であるかがわかります。

システムがあまりうまく設計されていないことを理解している場合、これはテスト駆動開発の使用を開始する方法について考える機会です。

最も簡単な例

サーバーに依存するクライアントがあります。クライアントはコンテキストに依存せず、テストは非常に簡単です。メソッドを呼び出して、出力を確認するだけです。サーバーのテストはより困難であり、クライアントと釘で結び付けられています。個別にテストするには、それらを分離する必要があります。

中間にインターフェースを挿入する必要があります。これで、クライアントに関係なくサーバーをテストできます。おそらく、多くは実装ではなくインターフェースに基づいたプログラムへのアドバイスを聞いたが、このアドバイスが良い理由を理解していなかった。

これは、なぜそうなのかを示すデモです。システムの設計に役立つ小さな独立した単体テストを作成する場合は、何らかの方法でコンポーネントを分離する必要があります。それらを分離するには、途中に何かを挿入する必要があります。この場合、それはインターフェースです。

インターフェースは、単に着信および発信パラメータのメソッドとシグネチャのコレクションではありません。インターフェースは契約でもあります。つまり、インターフェースに何かを要求するときに満足しなければならないクライアントの期待です。

インターフェイスにアクティブなユーザーを返すように依頼するとします。出力パラメーターにユーザーの配列があることを確認するだけでは十分ではありません。アクティブなものが必要です。そのため、「インターフェイス、アクティブなユーザーを教えてください！」と尋ねるテストを作成します。

そして、実際の作業を模倣します。実際の作業を行う必要がないため、独立したテストを作成します。

スタブは何らかの値を返します。

空の配列は、ユーザーがいないことを意味します。
1ユーザー-すぐにプロファイルに1ユーザーを入力します。
ユーザーが多い場合、テーブルのリストを表示します。

それだけです-私たちは3つのテストを書きました。ここでのタスクは、何らかの実装でコントラクトを実行することです。私たちは本当にデータベースに飛び込み、何かを得て、実際にアクティブなユーザーを獲得していることを確認します。契約インターフェースに従って行動します。

したがって、左側では、システムがインターフェースの異なる結果でどのように動作するかを具体的に指定します。右側では、システムが実際に期待を満たしているため、結果として、すべてが連携して動作します。

クライアントとサーバーの正確性を検証するために、クライアントとサーバーを一緒にテストする必要はありません。それで十分です：

正しく尋ねる
正しく処理する
正しく行動する
正しくチェックします。

それで十分です。

シンプルなデザインの4つのルール

このコンセプトは、ケントベックによって発明されました。優先度の順に、システムはすべてのテストに合格した場合、シンプルと見なすことができます。

システムにテストがない場合、またはコードがテストに合格しない場合、少なくともシステムの粘度が非常に大きいため、単純とは見なされません。そのようなコードは変更するのが怖いです、そして、これはシステムが腐敗し始めるので問題です。その結果、生産性が低下します。

テストは、コードが単純であると見なされるための前提条件です。

さらに、意図を明確にすることに集中できます。 コードをよく書かれた散文のように読むべきだと誰が言ったのか覚えていません。すべてのテストが機能した後、コードがよく書かれた散文として読まれることを確認し、 不要な重複を削除できます。

最後に、 最小数の要素で構成されるシステムについてはすでに考えることができます。

これらの人をソーシャルの友達として追加することをお勧めします。ネットワーク：

ケントベックは、エクストリームドライビングプログラミングおよびテスト駆動開発の分野の創設者です。
J. B. RainsbergerはJetBrainsの創設者です。
ロバート・マーティン -彼のことを知っていると思いますが、そうでない場合-彼のブログと本を読むことを最優先します。

それらを購読し、それらから例を取り、ブログを読み、彼らが書いたものを研究してください。

次は？

私はあなたに挑戦したいです。小さな演習に戻ります。適切に設計されていると思われるシステムに参加して、その上で小さな分離された単体テストを作成します。

ほとんどの場合、あなたはこれを行うことができないという事実に遭遇するでしょう、そしてあなたがそれについて何かをすることに決めたなら、私はあなたがこれらのリソースを見ることを勧めます：

https://cleancoders.com

https://online-training.jbrains.ca/p/wbitdd-01

この記事を読んでくれてありがとう。

Andreiに電報https://t.me/akolomenskyで手紙を書いて、エンジニアリング、プロセス、または製品のケースについて質問したり、アドバイスを求めたりすることができます。彼は皆に答えると約束したので、恥ずかしがらないでください。

私たちは、おそらく「 自分の技術を学ぶことをやめない 」という誓約条項を遵守するためではなく 、絶えず改善することに留意し、会議で会います。確かに、会議で得られた実践からのアイデアと事例の激しい流れは、少なくとも6ヶ月間、自己改善に弾みをつけます。そして、開発スケジュールが生産性の悪いスケジュールのように見えないように、今すぐ新しい料金を取得する時間です。RIT++フェスティバルは5月28と29日に、 Highload ++シベリア は6月25と26にノボシビルスクで開催されます。最後の4月30日までに、管理者は申請を提出することができます。

BackendConfを含む方向のプログラムRIT ++はすでに形成され始めており、あなたにとって特に有用なものを見つけ出し、チケットを予約することができます。たとえば、この記事のトピックで、2GISのYuri Badalyanetsによるトピック「Scalaでのマイクロサービスの統合テスト」に関するアプリケーション。彼はまた、単体テストでは十分ではないことが多く、統合テストも必要だと考えています。

分離された単体テストを使用して、システム設計を制御下に保つ