テスタースタイルの極端なプログラミング！

私の親愛なる皆さん、テストプロセスが逆行することを想像したことがありますか？ はいの場合、あなたはすでにTDDに精通しています！

ちょっとした歴史

次に、極端なプログラミングとテストの方法の1つについて説明します。 しかし、最初に-トヨタ！ はい、はい、これはトヨタです。私にとっては非常に良い車を作っている会社です。 彼らはテストとどう関係しているのでしょうか？ はい、最もすぐに！ いえ、180 km / hの速度でソフトウェアテストを行うわけではありません。 それは愚かだろう。 楽しいが、愚かな。



TDD（Test-Driven Development） 、または、私たちの意見では、テストに基づく開発は非常に興味深い手法ですが、私にとっては、TDDはよりクールに聞こえるので、ここでそれを呼び出します。 かっこいいですよね？



それで、私は何について話しているのですか？ ああ、トヨタ！ 大野泰一がTDDを開発したのはこの会社です。 この技術はもともと自動車製造に焦点を当てていました。 太一は廃棄物以外の生産に少し夢中になっており、すべてに加えて、賢明な日本の夢を実現するのに十分賢い人でした。 TDDの愛情深い母親であるTPSがいました。 彼の素晴らしいアイデアは、組み立ての最初の段階に必要な数の自動車部品のみを生産することでした。 また、これらの部品には非常に高い品質要件が課されていました。 生産のさまざまな段階の間のコミュニケーションのプロセスは、かんばん、またはより簡単に、必要な碑文とメモを備えた大きなボードのおかげで行われました。



しかし、これは車に関する話です。ソフトウェアテストとは何の関係がありますか？ 廃棄物の除去におけるすべての塩（私たちの場合、過度の努力）。 これは、一部のプロジェクトにとって重要な要因になる場合があります。 想像してみて、かなり日常的なシナリオを考えてみましょう。 わかりやすくするために。 あなたは顔の汗で働き、コードを書き、夜寝ないで、夕食時に電子レンジのディスプレイにコードを見ます。 そして、ここは美しい日です。 コードが追加されました。 しかし、誰もそれを使用しません。 数日、または数週間でさえ、コードを統合しません。 そして、急いで松葉杖で、彼らはプログラムに追い込まれます。 そして、いつすべてをチェックしますか？ パフォーマンスをテストするタイミング 繰り返しになりますが、職場で座って自分の想像力だけで眠りますか？ マーフィーの悪名高い法則から誰もが知っているように、最初からコードは単純に正しくありません（コードには少なくとも1つのバグがあり、コードが1行しかない場合でもバグが含まれます）。



または、コードが無駄になるだけです。 いいえ、もちろん、彼が書いたとき、目標はありましたが、その後、さまざまな理由により、その必要性は単に消えました。 涙するのは残念だ。 そして、もっと生産的なものに時間を費やすことができますよね？



ここでTDDが助けになります。 ユニットテストを忠実なかんばんとして、「生産の無駄」を減らすための正しい闘いの強力なモーゲンスターンとして。 そして最も重要なこと-すべてが時間通りに、タイムリーなフィードバックで行われます。 私にとっては素晴らしいボーナスです。

学ぶのは難しい...

指導では、つまり理論的には、すべてが非常にシンプルに聞こえますが。 TDDは一見すると非常に簡単に思えます。 少なくとも、彼には2つの基本的なルールしかありません。 上部が下部で下部が上部であるワンダーランドのルールは何ですか？ 見てみましょう：

• 新しいコードを書くのを忘れてください。 やめて キーボードから離れて安全な距離に移動し、全力で戦ってください。 少なくとも自動化があなたを失望させるまで。
• 繰り返さないでください。 互いに重複するすべてを排除します。

簡単そうですね。 しかし、これらのルールは従うよりも実装が簡単です。 これらのルールは、可能な限り正確にプロセスの複雑さを思い付くよう努めています。 そしてもう少し。



何度もルールに従う場合（そして、私たちは皆、燃えるキーボードや他のガジェットを備えたクールなTDDスピーカーであり、天国のクールさにプラスを加えているため）、テストするコードを書く前にテストを書く必要があります。 どうやら私たち一人一人が、ユラ・ガガーリンをenましく思っており、彼の人生で少なくとも一度は星を征服したいと思っています。 したがって、小さな例では、Javaを使用して、宇宙の潜在的な征服者のパラメーターを測定します。 なんで？ できるから！







この例では、テストコードは数行であり、生産的なコードは1行ではないという事実に驚かないでください。 これは、知覚を容易にするために設計された単なる例です。 それで、それで何が起こっているのでしょうか？

• オブジェクトを作成します。 宇宙船が正常に作成されました。 そして、通常の状態では、動きません。 したがって、その速度は毎秒0マイルです。 これは宇宙船の最も正確な定義ではありませんが、第一に、私は宇宙船の開発者ではありません。第二に、ロシアの慣習であるように、私たちの目的にとってはそうです。 各問題に順番に対処する必要があります。また、同僚がTDDの従業員に電話をかけるように、オーガニックデザインに取り組む必要があります。
• APIデザイン。 単体テストは最も幸運です。 彼らは自分自身で一粒のコードを試す最初の人になるでしょう。 そして、それに応じて、彼らは私たちに必要なデータを提供する最初の人になります。 ポイントは、このコードを書く前にデータを取得することです。 いいですね
• デカップリング 現時点では、宇宙船のクラスは特定の運動モデルから断頭されています（分離されています）。 彼が今知っているのは、標準のTDDテンプレートを表示できる「 運転モード 」インターフェースだけです。 設計の原則を含む文字列は、実装用ではなく、インターフェイス用にプログラムされています。 大きなプラスは、スタブ（ソフトウェアコンポーネントの動作のシミュレーション）によってテストされるユニットの対象になることです。 また、特定のクラスに過度に依存しないようにします。 通常、少なくとも1つの要因の不正確さが加わります。 そして、複数の不正確さはTDDが簡単に処理できるものではありません。
• 副作用。 運動モデルの変更は何を意味しますか？ 例に示すように、特定のモデルの最高速度に等しくなるだけです。

クラスの最初のテストケースは、必要な量の説明に圧倒される運命にあります。 最初だけだといいです これで、スターシップワンポイントゼロの作成を開始できます。







テストケースがあり、上記の例とは異なります。 実装が常に明らかではないようなケース。 次に、スタブ実装から始める価値があります。スタブ実装では、残酷に設定されたコードを元の値に戻す必要があります。 なぜこれをすべて行うのですか？ 主に、正しいことをテストしていることを保証するからです。 これは重要な要素です。なぜなら、体の成長により、必要なものが正確にテストされることを保証するのがはるかに難しくなるからです。



しかし、代替オプションの研究は簡素化されています。 これは、主要な機能に加えて、アンデッドを破壊し、義母の到着後に家を奉献し、それを醸造し、瓶詰めする、偉大なメガコードの祭壇に多大な努力が払われなかったという事実によるものです。 そして、これらの数行の怖いコード行を取り、消去することは心理的にも簡単です。 それはもちろん残念ですが、それほど多くはありません。 これで、テストを安全に実行して、子供のように緑のストライプを楽しむことができます。 喜んで手をたたくのは残忍で男らしい。 次に、重複する情報を見つけて排除するためにあらゆる努力をします。 改善できる点も確認できます。



私は与えられた例で何が嫌いですか？ 状態固有の速度。 速度は一度に2か所にあるため、複雑化もあります。 ここでは、「 運転モード 」が提供することによって、すべてを考慮してみましょう。







テストをもう一度実行した後、私の愛する高山色の草のストリップがJunitに表示されると信じていました（私は使用し、言及するのを忘れました、硬化が強くなったので、ごめんなさい）。 今、小さくてかなりの回帰テストを実行しています。

洗い流した後-古き良きひげを生やしたジョークが言うように、繰り返します

これらの小さな繰り返しがTDDの基礎です。 多くは行き過ぎです。 大きなステップを踏むことは非常によくある間違いです。 しかし、小さすぎることはすべきではありません。 ああ、オリンパスの神々、私が正しいバランスを見つけるまでどれだけ苦しんだのか。 結局のところ、非常に小さな部分ですべてを行うと、レッスンは通常その意味を失います。 それが速すぎると、フィードバック全体が失われ、すべてのデータが正しく機能します。 TDDソルトはすべて失われ、レッスンはさらに意味がなくなります。 しかし、ユニットが小さいほど大きい場合（ああ、非常にクールに聞こえます）、問題は簡単に見つかり、フィードバックが確立され、一般的に牧草地が咲き、ユニコーンがジャンプします。 これは、個人的な経験、壊れたキーボードの山、8階建てのロシア語の音節のトップにのみ基づいて見つけることができるバランスです。



小さなステップのもう1つの大きな利点は何ですか？ 迷わないでください。 結局のところ、電子メールは絶えず届き、電話は届きますし、気が散ることもあります。 または最悪の悪-「最愛の」同僚は、自分の黒い吸血鬼の心に棒を打ち込んでいるかのように鍵を叩いています。 気が散るよね？ しかし、小さなケースでは、すぐに労働生活の急速な流れに戻るのは非常に簡単です。 このケースは、忙しい一日を終えて明日から簡単に始めるのにも最適です。 そして、それが落ちたとしても、それはそれほどin辱的なものではなく、小さなものです。 しかし、このようなファイルは膨大な量のデータを提供するため、何を取得するかすぐにわかります。



残念ながら、繰り返しますが、正しいサイズは誰にとっても個人的な問題です。 そのようなセグメントの選択は、経験、知識、およびひげのレベルに基づいている必要がありますが、それ以外の方法は？

さまざまなレベルの設計

事前設計はどれくらい必要ですか？ 誰が知っている、これは答えられていないそれらの質問の1つです。 それはすべてプロジェクトに依存します。 私たちは、ボートのソフトウェアを引き続き使用します。 セキュリティ上の理由から、異常な状況での動作の1つが2つの異なるコマンドによって書き込まれたとします。 両チームは並行して動作するプログラムを作成していました。 プログラムには特定のパラメータが与えられ、何かに同意しない場合は、たとえば、起動が自動的にキャンセルされます。 この分離手法は、この場合の先行投資は互いに同意する必要がある2つの異なるソフトウェアであり、この効果を1つのプログラムから達成することは困難であることを示しています。

また、要件がわからない場合はどのようなテストを作成する必要がありますか？

多くの人がこの質問をしますが、私はかつて道に迷ったので、何に答えますか？ さて、プログラムするときにどのコードをスカルプトしますか？ 作成するものをどのように知っていますか？ 単体テストは要件に結び付けられるべきですか？ TDDは自信を持っていいえと答えます。



問題の全体的なポイントは、潜在的な問題の不気味な領域から要求が来るということです。 そして、私たち仲間の研究者たちは、穏やかな海岸から答えと修正、肥沃な海岸、若い処女、その他の喜びを上陸させようとしています。



TDDは詳細について焼き付けを提供しますが、あまり夢中にならないようにします。 その数を減らすようにしてください。 言い換えると、コード自体が書かれているのと同じ言語（最も重要なのは大文字の単体テスト）で単体テストを書いてください。

なぜこれらすべての海外TDDがありますか？

TDDとは何ですか？ そもそも、それを設計手法と考えたいと思います。 つまり、単体テストの開発者は、検証の重要な目的を果たします。 ただし、コードの正確性を検証することに同意する必要があります。 したがって、すべての自尊心のあるプロジェクトは、受け入れテストと要件テストを強制します。 単体テストは強力な基盤であり、全体を適切に機能させるために必要です。 これにより、TDDを使用して重要なことに集中できるようになり、普遍的な成功、喜び、そして多額のお金につながります。 あなたが言うものは何でも、楽園。



TDDのもう1つの非常に優れた機能は、それ自体がターゲットを検証する優れた方法であることです。 TDDでは、単体テストとコード自体の両方で、目標を2回指定する必要があります。 そして、それらが調和して適合する場合にのみ、緑のラインを楽しむことができます。

受け入れコード

コードカバレッジは非常に便利な手法です。 フィードバックを介して追加情報を取得するために使用されます。 単体テストの品質に関する情報。 分析システム自体をビルドに配置する必要があります。 したがって、単体テストを開始でき、レポート自体は1つのチームで受信されます。 ただし、少なくともモジュールの少なくとも1つのバージョンが完全に終了するまで、分析に夢中になってはいけません。



良いことは、マシンがあなたを失望させるまで、ルールに従って何度もコードをまだ書いていないという事実のために、TDDがあなたに100％のデータを（理論上）与えるということです。



コードカバレッジは、より多くの情報を取得し、壊れたウィンドウを修正するために必要なものです。

壊れた窓

まず、オペレーティングシステムを意味するものではないことに注意してください。 壊れた窓や玄関でできます。 それらについてお話します。 心理学にはこのような興味深い実験があります。 家の窓を1つ壊して修理しないと、時間の経過とともに家のすべての窓が壊れてしまいます。



そしてここにITがありますか？ あなたはすでに私がこれらすべてを導いているものを推測しているように思えます。 単体テストのないクラスは、壊れたウィンドウと呼ばれます。 彼が最終的に行うことは、単体テストを行わない余分な理由を捨てることだけです。 そして、それはますます悪化します。



コードはテストと同じ言語で書かれていないため（ほとんどの場合）、ウィンドウを修正するのは困難です。



ティーとクッキー以外の適切なTDDドライバーの反対側には何が待っていますか？ 既に存在するプログラムの拡張と「バグ」の機会。 もともとテスト言語で書かれていたため。 したがって、必要なテストを書き続けるだけで、熱いカモメ/コーヒー/ビール/白chを飲み、竹を吸うことができます。 あなたが望むなら、あなたは窓全体の意味を知っています、あなたは回帰でこの問題を軽くスパイスすることができます、そして、ここにそれはあります-幸福。 はい。コードが作成されており、以前にテストされていない場合、非常に顕著になります。 ウィンドウは突然鳴りますが、気付かないことはありません。

ソフトウェアケア

なんてこった、ソフトウェアに常にパッチを当てたり、リリース後にソフトウェアの世話をしたりするのがどれほど苦痛なのかなど。 ただし、TDDを使用すると、このプロセスの痛みを軽減できます。 これらの小さくて超高速の相互作用のおかげで、ソフトウェアは最初からメンテナンスの準備ができています。 はい、そして、それはすべてがカブトムシの駆除に便利であると言います。



では、どのようにして変更を成功させるのでしょうか？ TDDを使用すると、必要に応じてすべてに従うことができます。 つまり、ユニットテストと現在同時にテストされているユニットを変更しないでください。 何かを変更する必要がある場合は、それらを交互にします。 イベントの正しいフローは次のとおりです。

• 必要な変更を分析する
• 単体テストを実行する
• これらの詳細を書く
• 変更する必要があるものを理解します。 慣れているTDD手順に従ってください
• 勝利！

TDDの推奨事項

TDDは非常に厳しいものであり、厳しいものはすべて簡単に抜け落ちます。 したがって、真のハードコアTDD-shnikになりたい場合は、やり過ぎの価値があるもののリストがあります。

1. ユニットコードとテスト対象のコードは同等である必要があります。
2. 単体テストは、たとえばモナコと同じくらい小さく、独立している必要があります。
3. 永続的な名前を使用します。 あなたが慣れているトピック。 したがって、ナビゲーションが大幅に簡素化されます。 テストするユニットに応じて、ユニットテストに名前を付けます。

私たちは何を学びましたか？

もちろん、TDDは万能薬ではないので、この手法を痛いものすべてに適用すべきではありません。 そしてもちろん、彼女は暗闇の中で他のテクニックを公開しません。 TDDはあなたのためだけにあり、あなたに合っていればそれを使います。 ただし、TDDは、リリースの数時間前にショットガンやロケットランチャーのバグを発射して、狂ったように振る舞う手を走るよりも間違いなく優れています。 しかし、この面白いプロセスをテクニックとは呼びません。 私にとっては、これはただの予定外のアクションで、もっぱら面白い目標を持っています。



TDDが実際に行うのは、テストプロセスと開発プロセスの交換です。 同時に、高品質の設計とプロセスにおける優れた認識の中間点を見つけます。 しかし、TDDには規律と決意が必要であることを忘れないでください（決して）。



しかし、どんな人生の状況でもそうですが、選択は完全にあなた次第です。 私はあなたのすべての努力で幸運を祈り、顧客があなたを怒らせないようにし、松葉杖を出して、不快な些細なことのためにプロセス全体が酒石に飛ぶようにしてください！ すべての善の光線！