解釈の深さ - TDD詳細（テスト駆動開発）

本論文では、構造化されています。

TDDとは何ですか
なぜTDD
どのようにTDD
よくある質問
学習パス
深い読み

TDDとは何ですか

TDD広範かつ狭義には、狭義には、UTDD（ユニットテスト駆動開発）でTDDは、しばしば言われています。TDDは、BDD（ビヘイビア駆動開発）を含む、ATDD（受け入れテスト駆動開発）一般化と消費者主導契約の開発が似ています。
TDD TDDは狭義を指す本明細書で言及したように、それは、「ユニットテスト駆動開発」です。

TDDは、コアアジャイル開発手法や技術だけでなく、設計手法です。TDDの原理は、コードを書くために必要な製品を判断するためのコード、テストコードを書く前に、機能コード、ユニットテストケースの前に開発されています。TDDは、コア慣行のXP（エクストリームプログラミング）です。その主なプロモーターは、ケント・ベックです。

TDDは、3つの意味があります。

テスト駆動開発、テスト駆動開発。
タスク駆動開発、ミッション駆動開発、問題とタスク分解を分析します。
テスト中の保護を改善するために設計されたテスト駆動設計、。TDDが直接デザイン能力を向上しない、それだけであなたのデザインを保護し、改善するためのより多くの機会を提供します。

なぜTDD

TDDエンコーディングVS伝統的なエンコーディング

伝統的なエンコーディング

分析を必要とする、最初に書き始めました、気に誰の詳細を知りたいです
これは、需要の詳細は明らかにされていないことが判明し、ビジネスの人々に話を確認します
何回かを確認し、最終的にすべてのロジックを終えました
頼りにテストを実行している、それは実際に試運転、動作しません。
長い時間、最後に試運転作業
テスト、QA測定バグ、デバッグ、パッチを回し
最後に、コードが動作することができます
糞の腐った塊のようなコードを見てみると、動くことを恐れて、動きはQAテストが残業しなければならない、しなければならなかった、手動テストに持っていました...

TDDエンコーディング

最初のタスク分解、関心事の分離（プレゼンテーションが続きます）
列の例では、需要の例で、明確化の詳細を要求します
書き込みテストは、ニーズ、入力とプログラムの出力に焦点を当て、プロセスの途中気にしません
実現書き、他には何もこの小さな最も簡単な方法で、現在のニーズを満たすために必要はありません
道悪趣味を排除するためのコードと復興、
完成した、手動テスト、基本的に問題はない、問題があるが、ユースケースを作る、修理
ユースケースを作り、テスト、小さな問題を回し、修理
コードはきれいで、完全なユースケースで、自信を持って提出します

TDDのメリット

開発者の負担軽減
明確なプロセスを経ての、私たちは最初の一点、小さな思考の負担に焦点を当ててみましょう。

保護ネット
TDDの利点は、完全に私たちが簡単にできるように、製品コードは、セーフティネットを提供し、単体テストを覆われている変更のための需要を満たすか、デザインコードを向上させます。
あなたのプロジェクトが安定し、1回の仕上げを必要とするのであれば、それへの後続の変更は、TDDの恩恵を享受することはできませんが比較的小さいです。

アドバンス明確化は必要
コード書か半分だけ明確な需要を見つけていないのではなく、詳細を明らかにし、事前にニーズと要件について考えるように私たちを助けることができるテストを書くこと。

クイックフィードバック
多くの人々があるTDD、私のコード量が増大し、開発効率が低下していると言います。しかし、ユニットテストがない場合、あなたは手動テストに持って、あなたはフィードバックが非常に遅い、などジャンプインタフェースとして起動アプリケーション、データを準備するために多くの時間を費やしています。正確に言えば、フィードバックは、ユニットテストの迅速な利点です。

どのようにTDD

TDD

TDDの基本的な流れは次のとおりです。赤、緑、再建。
より詳細なプロセスは次のとおりです。

テストケースを書きます
テストを実行
ただ渡すテストを実現しましょう書きます
テストを実行
ところで、悪い味を識別することは、コードを変更します
テストを実行

あなたは、テストケースを書くために私に尋ねることがあり、それは明らかに失敗しますが、また、それを実行するために？
はい。あなたは、現在の障害は、障害のあなたの期待であることを確認するためにテストを実行し、両方のケースでの成功と失敗の唯一のテストは、しかし、数多くの複数の障害があることを考えるかもしれません。
すべては（コードは私の期待に沿った分前にまだあるので、それだけで変更されたコードによって引き起こされていなければなりません）エラーが発生した場合、あなたはすぐにエラーを見つけることができるように、期待に沿ったプログラムを可能にするためにあります。
このように、時間のデバッグコードの多くを節約できます。

TDDの3つのルール

それが失敗したユニットテストパスを作ることでない限り、それ以外の場合は任意の生産コードを書くことは許されません
ユニットテストでは、あなただけが（コンパイルエラーが失敗したとみなすことができる）だけ故障につながることができるようにコンテンツを書き込むことができます
唯一のあなただけの製品コードで失敗するユニットテストを作るために書くことができます

何の違反が起こるのだろうか？
最初の違反は、最初の製品コードを書き、そのコードは、必要なものを達成することですか？それは実際にそれを実装していることを確認するには？
テストは長い時間がかかることができない場合は、2番目の違反は、失敗したテストの数を書いて、その後、変更は、テストのコストを増加させ、テストを再構築することがあります、加えて、開発者の圧力を増加します。
第三条に違反して、製品コードが分からない場合、コードのこの部分には保護テストないだろう、現在のテストを超えて機能を実現するために手動テストの必要性は、正しいです。たぶんこれは、コードの複雑さを増す空中から、存在しない需要です。需要がある、そしてその次の試験が書き込まれる場合は、直接TDDのリズムを弱体化させます。

私はそれの本質があると思う：
懸念、一度だけ帽子の分離
需要、実装、設計：私たちのプログラミングの過程では、いくつかの懸念があります。
TDDは、私たちの一つの側面にそれぞれ焦点を明確に3つの手順を与えています。
赤：失敗のテストを書く、それが小さな需要の説明である、唯一の我々は、入力と出力を気にする必要があり、この時間は、単にどのように気にしません。
緑：これは、現在はほとんど需要で達成するための最速の方法の焦点は、他のニーズを気にしないし、コードのどのぞっとするような品質を制御しません。
復興：圧力のニーズを考えていない、また実装どちらも、単に悪趣味でコードを見つけて、コードがきれいなコードになることを可能にする方法でそれを排除する必要があります。

アテンション制御
人々の注目のどちらかのアクティブ制御、受動的にも魅了されます。注意は、それがより多くのエネルギーを消費し、前後に切り替えるには、以下の完全なとは思いません。
あなたはこのクラスを作成する場合はTDDの開発を使用して、我々はテストを書き、注意を制御するためのイニシアチブを取る必要があり、私はクラスが定義されていない見つけ、コンパイルエラーにIDEのヒント、行くためにこの時間は、あなたの注意をオンデマンドではない、とに切り替わりました実現は、我々は、このテストを終了し、それが正しい決定をした後、コンパイルエラーを排除するために開始する必要性を発現しているかどうかを検討することに焦点を当てる必要があります。

TDDなぜ多くの人々がそれをしないのですか？

スプリットタスクは合理的ではありません
TDD、小さな需要への大きな需要の解体前にタスクを分割します。
複数の機能をも除去することができます。

テスト書き込みませ
効果的なユニットテストで何を、多くの人があっても最終的には明らかではないが、何で測定、テストを書く、それもコンソール出力、視覚的な比較を検証するために、主張することができません。
良いユニットテストは、いくつかの原則を遵守する必要があります。

シンプルでのみテストを必要とします
考える-すると、その後のフォーマットに沿って
速いです
これは、アサーションが含まれています
繰り返すことができます

ただ実現書かないで
多くの人が誤っても実現他人のニーズを入れて、現在のニーズを筆記具に焦点を当てることができないとき、それはリズム感を損ないます。
ないときは小さな一歩を実装しました。

復興はないでしょう
香りを参照してください、クリーンコードが何であるかを理解し、そのようなあなたが再構成を開始したい場合など全くタイムリーな復興は、困難されていません。
私は臭いを除去するための正しい「方法」を知りません。

インフラ
特定の技術スタックのためには、ユニットテストは、テストを書くとき、それは不可能テストケースに注力すること、優れたインフラを構築していませんでした。

例

各単語が表示されますwords.txtテキストファイルの周波数を計算するプログラムを書きます。
物事をシンプルに保つために、それを前提としています。

小文字のみ、スペースを含めるwords.txt
各ワードは小文字のみが含まれています
1つ以上のスペースで区切られた単語の間

たとえば、次のようwords.txt含むことを前提としています

当日は晴れて
晴れのです

あなたのプログラムは、周波数逆の順序に従って、出力を次必要があります。

4は
3である
晴れた2
日の1

読みしないでください、あなたがどうなるかを考えます。
（... 3分を考えます）

この初心者はそれを得る必要があり、それはmain（）メソッド、擬似コードに書かれたすべてのコードを配置します次のとおりです。

main() {
    // 读取文件
    ...
    // 分隔单词
    ...
    // 分组
    ...
    // 倒序排序
    ...
    // 拼接字符串
    ...
    // 打印
    ...
}

非常に明確なアイデアが、多くの場合、終了1人の息で、最終的に稼働して、出力が期待されていないとして、その後、ポイントのデバッグを破るようになりました。

任意のカプセル化せずにこのようなコード。多くの人々は、いくつかの企業は、10以下の行の方法を制限して、それを飛んだことを聞く理由です、これは、ライン10は...私たちのビジネス・ロジックが非常に複雑で、ああ行うことができますことはできません
ので、コードのどのような種類が存在します問題は？

テスト不能
再利用することはできません。
問題を特定することは困難

さて、我々はどのように書くことがTDDさて、あなたが読んでと言うファイル、コンソール出力テストコードを来りますか？
もちろん、我々はモックとスタブによってIOを分離することができますが、本当に必要？

誰かが、このような質問ケント・ベックを尋ねました：

あなたが本当にそれを何を測定するのでしょうか？でもゲッターとセッターはそれをテストしますか？

ケント・ベック氏：会社ではなく、テストコードを書くので、ビジネス価値を実現するために来るように頼みました。
だから、僕は場所に自信をテストコードを書いていません。

それは我々のプログラムのために、文書を読み、コンソールに出力すると、呼び出し側のシステムのAPIである、それは非常に自信を持ってすることができます。大半は、中央の書き込みが独自のビジネスロジックを記述するために自信を持っていません。
だから我々は、いくつかのパッケージプログラムを行うことができ、「コードのクリーンな方法を、」レーンは場所ではなく、注意抽出方法、メソッド名を注釈を付けることができ、言いました：

main() {
    String words = read_file('words.txt')
    String[] wordArray = split(words)
    Map<String, Integer> frequency = group(wordArray)
    sort(frequency)
    String output = format(frequency)
    print(output)
}

これは別のことではありませんsplit、group、sort、format行うユニットテストを書くための方法はありますか？
確かに、彼らの入力と出力が非常に明確なものです。

ように、あなたはテスト駆動設計、ないと言うかもしれませんか？どのように設計を開始するのですか？良い質問！

TDDはそれを進めるために設計されたいですか？

ケント・ベックが事前に設計されていません、彼は、最も簡単なユースケースのいずれかを選ぶだろうテストに合格するための最も簡単なコードで、直接開いて書き込みます。コードが複雑になるように徐々にデザインを駆動するために復興して、テストを高めます。
この要求では、最も単純なシナリオは、それは何ですか？
つまり、出力が空で、ファイルが空である、です。

もちろん、複雑な問題のために、あなたは、ユースケースを書きながら、新しい側面を追加したいかもしれませんが、この単純な問題のために、基本的にはどのような製品コードを駆動するために例を使用しているもの事前に知りたいと思いました。
あなたは、おそらく次の使用例を考えることができます。

"" => ""
「彼」=>「彼1」、フォーマットされたコード列から追い出さ語、
=>「彼は1 \ R \ NIS 1」、コードワードのうち、駆動される2つの異なる単語を、セグメンテーション「彼はあります」
=>「彼2 \ R \ NIS 1」、コードパケットは同じ単語追い出さ「彼と彼はあります」
「彼はである」=>は、ソートコード・パケットを駆動する「2 \ Rの\のNHE 1」
「彼は1 \ rを\ NIS 1」、複数のスペース、コードワードの完璧な部門=>「彼はあります」

Martin Fowler氏の見解は、私たちが行うには、コード記述の前に、ということであるビッグデザインアップフロントをうまくすべての詳細を設計するためのコードを記述するために開始する前に、。
私たちは、このツールを再構築した後と、理由はテストコード保護たくさんの小さな設計圧力を行い、私たちは常に現実を再構築することができます。しかし、これは我々が設計を進めるために必要がないことを意味するものではありません、事前に設計、我々は他の人と議論できるように、コードを書き始める前に、あなたが最初の数回の反復紙の繰り返しにコードを変更することができますが速くよりも優れています。
私は個人的に、私はテストを通じて、最も単純な実装を使用しますが、設計を行う（もちろん、私の心は十分ではありませんので、紙の絵）まず念頭に置いて、Martin Fowler氏の練習に同意した後、数回の反復の後に書き始めましたので、しかし、より効率的な方向の再構築、そこにあります。

戻るこのプログラムに、私は現在のパッケージは、抽象化のレベルではありませんが、デザインがより望ましいことがわかりました。

タスク分解

main() {
    String words = read_file('words.txt')
    String output = word_frequency(words)
    print(output)
}

word_frequency(words) {
    String[] wordArray = split(words)
    Map<String, Integer> frequency = group(wordArray)
    sort(frequency)
    return format(frequency)
}

このとき、二つの選択肢があり、それは私が個人的にかつてのを好む、のようだったトップダウン、ボトムアップのようでした。

あなたは改造サイクルを行うことができます-緑-今、ちょうど赤に従ってください。
大半は、TDD先行タスクとのコラム例のない分解プロセスが存在しないことを、行って。
TDDは、あなたがする私を参照することができ、プロセスを見たいと思って生きて。
必要な場合は、私はこのトピックに関する動画を記録することができます。

よくある質問

なぜ最初ではないの後にテスト、試験と補足を記述する必要がありますか？

OK、しかし達成するために仕上げた後、すぐに実装を確認するためのテストでテストを書きます。あなたの最初の手動テストは、コードをデバッグすることは良好な状態であれば、ユニットテストを修正、あなたは非常に悲しいが、また、ワークロードが増加します。
かどうか試験後の最初の行と高速フィードバックを楽しみますが、最初のテストならば、あなたは別の利点、少ないリワークを使用して目的駆動型のプログラミングを楽しむことができます。テストコードは、クライアント（呼び出し側）の製品コードがあるので、あなたは（メソッド名、パラメータ、戻り値、など）、に書き込むための書き込み後に比べて、テストコードでの製品コードを実現するために行くようにあなたの理想的な外観を書くことができますテスト、かつての少ないリワーク。

ただ、実装書いていない、テストを書きます。あなたがテストでエラーが実行されることを知って、なぜランニングに行きますか？

実際には、が運営するテストの結果ではなく2だけではなく、可能な多くがあるので、渡されません。我々は、特定の障害状態がテストを実行し続け知っているように、目的は、それが必要なその間違いを報告しているかどうかを確認することです。

小さな進歩は本当に良い、しかし、あなたは本当にそのような小さなステップを必要としますか？

舞のペースがあまりにも簡単に卵を引っ張りました。
練習時間は仕事が自由にペースのサイズを切り替えることができたときに、小さなステップの習慣を開発する必要があります。
とき、あなたはすぐに小さなステップモードに切り替えることができたときにあまり自信を持っているときに、その大きなポイントにステップ自信。唯一の大きな場合、小さな一歩を再することは困難です。

コードは、メンテナンスの負担になりますかどうかをテストするには？

TDDは、テストが失敗したように、ニーズの変化を世話するためにテストコードを変更する保守手順に従ってください、その後、製品コードでそれを修正します。
だから、テストケースの維持にはなく、テストケースの使用ではありません。

なぜすぐに達成すべき？

テストに合格していない場合は実際には、テストを通じて達成打ちで問題がないかを決定するための基本的なテストを問題を特定するための二分法を見つけることです、そして製品コードを達成するために行く、問題は製品コードです。
主に問題を特定するので、小さな進歩は、つまり、あなたはデバッグにさよならを言うことができます。

テストコードは非常にシンプルなものにするのはなぜ？

テストが失敗した場合は、とき修理がひどく書かれているテストコードの代わりに、製品コード、テストコードを変更することです。
テストコードが十分に単純である場合は、テストが失敗した場合、問題のコードでは製品の十分な自信があると結論しなければなりません。

ときTDDには適していませんか？

あなたが探索研究と技術（スパイク）している場合は、それだった高価な手動テストを構築するために、長期的なメンテナンス、およびテストインフラストラクチャを必要としません。
「非常に悪いテスタビリティレガシーシステム」と「使用テスト無愛想な技術スタック」システムもありますが、TDDは良いよりも害を行うことができます。

学習パス

「効果的なユニットテスト。」
「コードきちんとした方法」
「復興」
転換優先前提
「例により、テスト駆動開発」
「テストに導かれ、オブジェクト指向ソフトウェアを育てます」

深い読み

この記事はもともとGitChatに掲載されていました、記事が無料で公開されている、Q＆録音を購入することを歓迎します。

オリジナル住所：https://www.jianshu.com/p/62f16cd4fef3