あなたはいつTDDに "本当の"コードを書いていますか?

johnny 08/19/2017. 11 answers, 20.464 views
tdd

私が読んで訓練のビデオで見たすべての例は、単純な例を持っています。 しかし、私が緑色になった後、私が "本当の"コードをどうやって行うのか分からない。 これは "リファクタリング"の部分ですか?

複雑なメソッドを持つかなり複雑なオブジェクトを持っていて、テストを行い、それを通過させるために最小限のテストを書いています。 いつ私は戻って実際のコードを書くのですか? そして、再テストする前にどれくらいの実際のコードを書いていますか? 私は最後の方が直感であると推測しています。

Edit:すべての人に感謝します。 すべてのあなたの答えが私を大いに助けました。 私が尋ねているか混乱しているかについてはさまざまな考えがあるようですが、おそらくそこにはありますが、学校を建設するための申請書があります。

私の設計では、私が最初にやってみたいアーキテクチャ、User Storiesなどがあります。 ここから、私はそれらのユーザーストーリーを取り上げ、ユーザーストーリーをテストするためのテストを作成します。 ユーザーは、私たちは、学校に入学して登録料を支払う人がいると言います。 だから、私はそれを失敗させる方法を考えています。 そうすることで、私はクラスX(おそらく学生)のテストクラスを設計します。これは失敗します。 私はクラス "学生"を作成します。 たぶん "学校"私は知らない。

しかし、いずれにしても、TD Designは私にその物語を通して考えることを強いられています。 テストを失敗させることができれば、なぜ失敗するのか分かりますが、これは私が合格させることを前提としています。 それは設計についてです。

私はこれを再帰について考えてみましょう。 再帰は難しい概念ではありません。 あなたの頭の中でそれを実際に追跡するのはもっと難しいかもしれませんが、現実には、最も難しい部分は、再帰が "壊れる"とき、いつ停止するべきかを知ることです(私の意見はもちろんです)。最初の再帰。 それは不完全な類推だけであり、各再帰的反復は「合格」であると仮定している。 再び、ちょうど意見。

実装では、学校は見えにくいです。 数値と銀行の元帳は単純な算術を使用できるという意味では「簡単」です。 私は+ bと0を返すことができます。人のシステムの場合、私はそれをどのようにimplementするかについてもっと考える必要があります。 私は失敗、合格、リファクタリングのコンセプトを持っています(主に研究とこの質問のためです)。

私が知りませんが私の意見では、経験の欠如に基づいています。 私は新しい学生のサインアップに失敗する方法を知らない。 私は姓を入力して誰かがデータベースに保存されて失敗する方法を知らない。 私は単純な数学のために+ 1を作る方法を知っていますが、人間のような実体を使って、私が誰かが名前を入力するときにデータベースの一意のIDなどを返すかどうかをテストするだけではわかりません。データベースのいずれか、または両方を使用するか、

または、これは私がまだ混乱していることを示しているかもしれません。

5 Comments
187 hobbs 07/25/2017
TDDの人々が夜のために家に帰った後。
14 Goyo 07/25/2017
なぜあなたが書いたコードが本当ではないと思いますか?
2 johnny 07/26/2017
@RubberDuck他の答えよりも多くのことがありました。 私はすぐにそれを参照すると確信しています。 まだ外国人ですが、私はそれをあきらめません。 あなたが言ったことは意味がありました。 私は自分の文脈や通常のビジネスアプリケーションで意味をなさないようにしようとしています。 おそらく目録システムなど。 私はそれを考慮する必要があります。 私はあなたの時間に感謝しています。 ありがとう。
1 Edmund Reed 07/26/2017
答えはすでに頭で釘打ちされていますが、すべてのテストが合格で、新しいテストや機能は必要ない限り、あなたが持っているコードは完成したと見なすことができます。
3 Borjab 07/26/2017
問題には、「私は複雑な方法でかなり複雑なオブジェクトを持っている」という問題があるかもしれません。 TDDではまずテストを書くので、かなり簡単なコードから始めます。 これにより、モジュラーである必要がある、テストにやさしい構造をコード化するようになります。 複雑な動作は、よりシンプルなオブジェクトを組み合わせることによって作成されます。 かなり複雑なオブジェクトやメソッドで終わると、リファクタリング時です

11 Answers


RubberDuck 07/27/2017.

複雑なメソッドを持つかなり複雑なオブジェクトを持っていて、テストを行い、それを通過させるために最小限のテストを書いています。 いつ私は戻って実際のコードを書くのですか? そして、再テストする前にどれくらいの実際のコードを書いていますか? 私は最後の方が直感であると推測しています。

あなたは "戻る"と "実際のコード"を書くことはありません。 それはすべて実際のコードです。 あなたがやることは、新しいテストをパスするためにコードをchangeするようにforcesする別のテストを追加することです。

あなたが再テストする前にどれくらいのコードを書いていますか? なし。 失敗したテストをせずにzeroコードを書いて、より多くのコードを書くようにします。

パターンに気づく?

それが役立つことを望む(別の)簡単な例を見てみましょう。

 Assert.Equal("1", FizzBuzz(1)); 

簡単なピージー。

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

実際のコードとは違うものでしょうか? 変更を強制するテストを追加しましょう。

 Assert.Equal("2", FizzBuzz(2)); 

if n == 1ように何か愚かなことができるかもしれませんが、純粋な解にはスキップします。

 public String FizzBuzz(int n) {
    return n.ToString();
} 

クール。 これは、FizzBu​​zz以外のすべての番号で機能します。 プロダクションコードを強制的に変更する次の入力は何ですか?

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

そしてまた。 まだ合格しないテストを書く。

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

これで3つの倍数をすべてカバーしました(これは5の倍数でもないので、それを書き留めて戻ってきます)。

私たちはまだ "バズ"のテストを書いていないので、それを書きましょう。

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

もう一度、私たちが扱う必要がある別のケースがあることがわかります。

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

これで、3の倍数ではない5の倍数をすべて処理できます。

この時点までは、リファクタリングの手順を無視していましたが、いくつかの重複があります。 今、それをきれいにしましょう。

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

クール。 今度は重複を削除し、うまく機能を作成しました。 私たちがコードを変更するように強制する次のテストは何ですか? さて、私たちは、数字が3と5の両方で割り切れる場合は避けています。今すぐ書きましょう。

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

テストは合格しますが、重複しています。 私たちにはオプションがありますが、 "ローカル変数の抽出"を数回適用して、リライトするのではなくリファクタリングします。

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

すべての合理的な情報をカバーしましたが、 unreasonable入力はどうですか? 0または負の値を渡すとどうなりますか? これらのテストケースを記述します。

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

これはまだ「実際のコード」のように見え始めていますか? もっと重要なのは、どの時点で「非現実的なコード」となることを止め、「本当の」状態に移行するのか? それは熟考するものです...

だから、私は各ステップで合格しないと知っていたテストを探すだけでこれを行うことができましたが、私は多くの練習をしました。 私が仕事をしているときは、これほどシンプルなことはありませんし、どのテストが変更を強制するのかは分かりません。 時々私はテストを書いて、それがすでに合格しているのを見て驚くでしょう! 始める前に「テストリスト」を作成するという習慣を身につけておくことを強くお勧めします。 このテストリストには、あなたが考えることができるすべての「面白い」インプットが含まれているはずです。 それらをすべて使用することはできませんし、あなたが行くにつれてケースを追加する可能性がありますが、このリストはロードマップとして機能します。 FizzBu​​zzのテストリストは、このようになります。

  • ゼロ
  • 1
  • 6つ(3の3の倍数)
  • ナイン(3乗)
  • 10(5の単純な多項式)
  • 15(3&5の倍数)
  • 30(3および5の非自明の倍数)
5 comments
3 maple_shaft♦ 07/27/2017
コメントは議論の延長ではありません。 この会話はチャットに移動さました
40 GManNickG 07/27/2017
私はこの答えを完全に誤解していない限り、「n == 1のように愚かなことをすることができますが、われわれは純粋な解決法にスキップします。 - すべてがばかげていた。 前を知っているなら<spec>を実行する関数が必要です。<spec>のテストを書いて、明らかに<spec>に失敗したバージョンを書き込む部分はスキップしてください。 <spec>にバグを見つけたら、まず、テストを書いて、修正の前にテストを実行し、修正の後にテストが合格することを確認します。 しかし、これらすべての中間ステップを偽造する必要はありません。
15 user3791372 07/28/2017
この回答の主な欠陥とTDDの一般的なコメントはチャットに移されました。 TDDの使用を検討している場合は、「チャット」をお読みください。 残念なことに、「品質」のコメントは、未来の生徒が読むチャットの中に隠されています。
nbro 07/28/2017
あなたがこの答えを改善したいのであれば、この "テストリスト"の内容に関してもっと正確になります。 私は明示的に "境界値"と "クラス分け"について話すでしょう。
2 hvd 07/30/2017
@GManNickG私はポイントがテストの適切な量を得ることであると信じています。 テストをあらかじめ書くことで、テストで特別なケースをテストする必要があり、テストで十分にカバーされていない状況、またはテストで重大な時間が無意識にカバーされている状況につながります。 あなたがこれらの中間ステップなしでそれを行うことができれば、素晴らしい! 誰もがまだそれを行うことはできませんが、それは練習が必要なものです。

GenericJon 07/24/2017.

「本当の」コードは、テストを合格させるために書くコードです。 Really 。 それは簡単です。

テストを緑色にするために最小限のものを書くことについて人々が話すとき、それは単にあなたの実際のコードがYAGNIの原則に従うべきことを意味します。

リファクタリングのステップのアイデアは、要件を満たしていれば満足していると書いたものをクリーンアップするだけです。

あなたが書いたテストが実際にあなたの製品要件を取り囲んでいれば、一度それらが合格すれば、コードは完成します。 あなたのビジネス要件のすべてにテストがあり、それらのテストのすべてが緑色であれば、それについて考えてみてください。 (さて、実生活では完全なテストカバレッジは得られませんが、理論は健全です。)

5 comments
44 Derek Elkins 07/24/2017
単体テストは、比較的簡単な要件であっても、実際には製品要件を網羅することはできません。 せいぜい、彼らは入出力の空間をサンプリングします。その考え方は、あなたが(正確に)完全な入出力空間に一般化することです。 もちろん、あなたのコードはすべてのテストに合格し、他の入力に失敗する各単体テストのケースを持つ大きなswitchすぎないかもしれません。
8 Taemyr 07/25/2017
@DerekElkins TDDは失敗したテストを要求します。 ユニットテストに失敗しない。
6 jonrsharpe 07/25/2017
@DerekElkinsだからこそユニットテストを書くだけでなく、なぜそれを偽造したくないという一般的な前提があるのですか?
35 Derek Elkins 07/25/2017
@jonrsharpeそのロジックによって、私は決して簡単な実装を書いていないでしょう。 たとえば、RubberDuckの答え(単体テストのみを使用する)のFizzBu​​zzの例では、最初の実装は明らかに「ちょうど偽造」しています。 この質問に対する私の理解は、あなたが不完全であることを知っているコードを書くことと、本当のコードであることを真に信じるコードとの間のこの二分法です。 私の「大きなswitch 」は、「テストをグリーンにするための最低限の書き込み」という論理的な極端なものとして意図されていました。 私はOPの質問を次のように見ています.TDDでは、この大きなswitchを避ける原則はどこですか?
2 Luaan 07/25/2017
@GenericJonそれは私の経験ではあまりにも楽観的です:) 1つは、無意味な繰り返し仕事を楽しむ人がいます。 彼らは "複雑な意思決定"よりも巨大なスイッチの声明でより幸せになるでしょう。 彼らの仕事を失うためには、彼らはテクニックでそれらを呼び出す人が必要です(そして、彼らは実際には会社の機会/お金を失っているという良い証拠を持っている方が良いでしょう)、あるいは例外的に悪いです。 このような多くのプロジェクトのメンテナンスを引き継いだ後、私は顧客が幸せになる(そして支払う)限り、非常に未知のコードが何十年も続くことは容易だと言えるでしょう。

Carl Raymond 07/24/2017.

簡単な答えは、「実コード」がテストを合格させるコードであることです。 実際のコード以外でテストをパスすることができれば、テストを追加してください!

私は、TDDに関するチュートリアルの多くが単純であることに同意します。 それは彼らに対して働く。 たとえば、3 + 8を計算するメソッドの単純すぎるテストは、実際には選択肢がありませんが、3 + 8を計算して結果を比較することもできません。 これは、コード全体を複製するだけのように見えます。そのテストは、無意味でエラーが発生しやすい余分な作業です。

テストがうまくいくと、アプリケーションの構造やコードの記述方法がわかります。 賢明で有益なテストがうまくいかない場合は、おそらくデザインを少し考え直すべきでしょう。 うまく設計されたシステムは簡単にテストできます。つまり、賢明なテストは考えやすく、実装するのが簡単です。

テストを最初に書いたときに失敗したことを確認し、それをパスするコードを書くと、それはすべてのコードに対応するテストがあることを保証する規律です。 私がコーディングしているとき、私はそのルールに従うことは怠惰ではありません。 私はしばしば事実の後にテストを書く。 しかし、最初にテストをすることは、あなたを正直に保つのに役立ちます。 経験があれば、テストを最初に書いていなくてもコーナーに自分自身をコーディングするときに気付き始めるでしょう。

4 comments
6 Steve Jessop 07/26/2017
個人的には、 assertEqual(plus(3,8), my_test_implementation_of_addition(3,8))ではなくassertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) assertEqual(plus(3,8), 11)というテストを記述します。 より複雑なケースでは、テストで正しい結果を動的に計算し、等価性をチェックするother thanに、常に正しい結果を証明する手段を探します。
Steve Jessop 07/26/2017
ですから、この例では、実際には愚かなやり方で、 plus(3,8)が3を減算して8を減算し、結果を0でチェックして正しい結果を返したことを証明できます。これは明らかですassertEqual(plus(3,8), 3+8)同じですが、テスト対象のコードが単なる整数よりも複雑なものを構築している場合は、結果を取得して各部分の正しさをチェックすることがよくあります正しいアプローチ。 あるいは、 for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
...それは大きな恐怖を避けるからです。テストを書くときに、私たちがライブコードで作った「10を加える方法」という主題に関して同じ誤りを犯すということです。 そのため、テストでは、何かに10を加えたコードを書くのを慎重に避けています。 もちろん、プログラマが検証した初期ループ値に依然として依存しています。
3 Warbo 07/28/2017
事実の後でテストを書いているとしても、それが失敗するのを見ることはまだ良い考えです。 あなたが取り組んでいることには重要であると思われるコードの一部を見つけ、少し変更する(例えば+を - などに置き換える)、テストを実行して失敗を監視し、変更を元に戻してパスするのを見ます。 私はこれを何度もやったことがあります。実際にテストが失敗するわけではなく、役に立たないより悪くなります。何もテストしていないだけでなく、何かがテストされているという誤った信頼を与えています。

Victor Cejudo 07/25/2017.

TDDに関するいくつかの例が誤解を招くことがあります。 他の人が以前に指摘したように、テストを行うために書くコードは実際のコードです。

しかし、実際のコードが魔法のように見えるとは思わないでください。間違っています。 最も簡単なケースやコーナーケースから始めて、それに応じてテストを選択する必要があります。

たとえば、レクサーを書く必要がある場合は、空の文字列で始まり、次に空白の束で始まり、次に数字、次に空白で囲まれた数字、間違った数字などで始まります。正しいアルゴリズムですが、最も簡単なケースから非常に複雑なケースにジャンプして、実際のコードを完成させることはありません。

ボブ・マーティンはここで完全に説明します


CandiedOrange 07/25/2017.

リファクタリングパーツは、疲れて帰宅したいときにクリーンアップします。

フィーチャーを追加しようとしているときは、次のテストの前にリファクターパーツを変更します。 あなたは、新しい機能のためのスペースを作るためにコードをリファクタリングします。 あなたは、その新しい機能が何であるかをknowているときにこれを行います。 あなたが想像している時ではない。

これは、 GreetMomクラスを作成して(テストを追加した後)、「Hi Mom」を印刷する機能を追加する前に、 GreetImplGreetWorldに変更するGreetImpl簡単に行うことができます。


graeme 07/27/2017.

しかし、実際のコードは、TDDフェーズのリファクタ・ステージに現れます。 つまり、最終リリースに含まれるべきコードです。

テストは、変更するたびに実行する必要があります。

TDDライフサイクルのモットーは次のようになります: RED GREEN REFACTOR

RED :テストを書く

GREEN :可能な限り迅速にテストに合格する機能コードを取得しようと正直な試みをしてください:重複コード、あいまいな名前の変数、最高位の注文など

REFACTOR :コードをクリーンアップし、変数に適切な名前を付けます。 コードをDRYしてください。

5 comments
5 mcottle 07/25/2017
私はあなたが "グリーン"フェーズについて何を言っているのかは知っていますが、テストをパスするハードワイヤリングの戻り値が適切かもしれないことを意味します。 私の経験では、 "グリーン"は、要件を満たすための作業コードを作成する正直な試みでなければなりません。完璧ではないかもしれませんが、開発者が最初のパスで管理できるように完全で "流通可能"でなければなりません。 おそらく、リファクタリングは、開発をやり遂げた後のある時期に最もよく行われ、最初のパスの問題がより顕著になり、DRYの機会が生まれます。
graeme 07/25/2017
@mottle私はこれらのすべてを同じタスクの一部と見なします。 それを完了させてから、それを掃除してください。 さらなるリファクタリングは、他のタスクの一部として時間が掛かるにつれて行われるべきである。
1 Bryan Boettcher 07/25/2017
@mcottle:get-onlyリポジトリの実装がコードベースでハードコードされた値になる可能性があります。 :)
6 Kaz 07/25/2017
私が入力できるように素早く素敵な生産品質のコードを作り出すことができるとき、なぜ私はこれまでにクラップスコードを書いてそれをクリーンアップするのですか? :)
1 Kaz 07/27/2017
@TimothyTruckle可能な限り簡単な変更を見つけるには50分かかりますが、2番目に簡単な変更を見つけるためには5つしかありませんか? 私たちは二番目に簡単に行くのでしょうか、それとも簡単なことを探し続けていますか?

Timothy Truckle 07/27/2017.

あなたはいつTDDに "本当の"コードを書いていますか?

red段階はコードをwrite場所です。

refactoring段階では、主な目的はコードをdeleteです。

redフェーズではas quick as possibleテストを合格as quick as possibleせるために何でもしていat any cost 。 あなたは、良いコーディング実践やデザインパターンを耳にしたことはありません。 テストを緑色にすることはすべて重要です。

refactoringフェーズでは、今作成したばかりのものをクリーンアップします。 これで、 変換の優先順位のリストの一番上の種類であるかどうかをまず確認し、コードの重複がある場合は、デザインパターンを適用して最も可能性の高いものを削除できます。

最後に、識別子の名前を変更して、 magic numbersやリテラル文字列を定数に抽出することで、可読性を向上させます。


それは赤 - リファクターではなく、赤 - 緑 - リファクターです。 - Rob Kinyon

これを指摘してくれてありがとう。

real codeを書くのはgreen段階real code

red段階では、 executable specificationを書いていexecutable specification ...

2 comments
Rob Kinyon 07/27/2017
それは赤 - リファクターではなく、赤 - 緑 - リファクターです。 「赤」は、テストスイートを緑色(すべてのテストが合格)から赤色(1回のテストが失敗)にすることです。 「緑色」は、テストスイートを赤から(1つのテストが失敗して)緑色に(すべてのテストが合格)不合理にぶつかるところです。 「リファクタ」は、すべてのテストを通過させながらコードを取得し、それをきれいにする場所です。
Timothy Truckle 07/27/2017
@ RobKinyonありがとう、答えを更新しました。

Robert Andrzejuk 07/27/2017.

あなたはいつもReal Codeを書いています。

各ステップで、あなたのコードがあなたのコードの今後の発信者(あなたがそうであってもなくてもよい)のために満たす条件を満たすコードを書いています。

あなたはあなたがそれをリファクタリングするかもしれないので、あなたは有用な( real )コードを書いていないと思います。

コードリファクタリングは、外部の動作を変更することなく、ファクタリングを変更して既存のコンピュータコードを再構築するプロセスです。

つまり、コードを変更しても、コードが満たされた条件は変更されません。 また、あなたのコードが既に存在していることを確認するために実装したチェック( tests )によって、変更によって何かが変更されたかどうかが検証されます。 だからあなたが書いたコードは、ちょっと違う形でそこに書かれています。

あなたが実際のコードではないと思う別の理由は、エンドプログラムがすでにあなたの目をとめることができる例を実行しているということです。 これは非常に良いです、あなたがプログラミングしているdomainについての知識を持っていることを示しています。
しかし、プログラマは何度もnew domainであり、それはunknownれていません。 彼らは最終結果がどうなるか分からず、TDDはプログラムを段階techniqueに書くtechniqueあり、このシステムの仕組みやコードがそのように機能するかどうかのknowledge文書化しています。

私がTDDでThe Book(*)を読んだとき、私にとっては目立つ最も重要な機能は:TODOリストでした。 TDDは、開発者が一度に1つのことに集中できるようにする技術でもあることがわかりました。 これはあなたの質問に対する答えです。 How much Real code to writeですか? 私は一度に1つのことに集中するのに十分なコードを言うでしょう。

(*)「テスト駆動開発:例で」ケント・ベック

1 comments
2 Robert Andrzejuk 07/27/2017
「テスト駆動開発:例で」Kent Beck

Zenilogix 07/31/2017.

テストを失敗させるコードを書いているわけではありません。

あなたは、成功するかどうかを定義するためにテストを書いています。あなたは、合格するコードをまだ書いていないので、最初はすべて失敗するはずです。

最初に失敗したテストを書くことについての全体的なポイントは、2つのことをすることです。

  1. すべてのケースをカバーする - すべての名目ケース、すべてのエッジケースなど
  2. テストを検証します。 あなただけが通過するのを見た場合、どのようにして障害が発生したときに確実に障害を報告することができますか?

赤と緑のリファクタの背後にあるポイントは、正しいテストを最初に書くことは、テストに合格するために書いたコードが正しいことを自信が持てるようにし、テストがあなたにすぐに通知するという確信でリファクタリングすることができるということです。何かが壊れてしまうので、すぐに戻って修正することができます。

私自身の経験(C#/ .NET)では、まだ存在しないメソッドへの呼び出しをコンパイルすることができないため、純粋なテストファーストは、達成できない理想のビットです。 だから、 "テストファースト"は、実際にインタフェースを実装し、実装を最初にスタブした後、スタブが正しく展開されるまでスタブに対してテストを書くことです。 私はスタブから構築するだけで "失敗したコード"を書いていることはありません。


Zan Lynx 07/27/2017.

単体テストと統合テストの間で混乱するかもしれないと思います。 受け入れテストもあると思いますが、それはあなたのプロセスに依存します。

あなたがすべての小さな "ユニット"をテストしたら、すべてのアセンブリをテストするか、または "統合"します。 これは通常、プログラム全体またはライブラリです。

私が書いたコードでは、データを読み込んでライブラリにフィードし、結果をチェックするさまざまなテストプログラムを使ってライブラリをテストします。 それから私はスレッドでそれを行います。 それから、私はスレッドとfork()を中央で実行します。 それから私はそれを実行し、2秒後にkill -9を実行してから、起動し、回復モードを確認します。 私はそれをかわいそうだ。 私はあらゆる種類の方法でそれを拷問します。

そのすべてがALSOテストですが、私は結果のためにかなり赤色/緑色の表示がありません。 それは成功するか、何千ものエラーコードを調べてその理由を調べます。

それが「実際のコード」をテストする場所です。

そして、私はこれについて考えましたが、あなたがユニットテストを書くことがいつ予定されるのか分からないかもしれません。 あなたはあなたのテストがあなたがするべきことを指定したすべてを行使すれば、単体テストを書くことができます。 場合によっては、エラー処理やエッジケースの中でそのことを把握できない場合があります。そのため、単純に仕様を順調に実行する素敵なパステストのテストグループを作成したい場合があります。

1 comments
Peter Mortensen 07/27/2017
(その=所有権、それは=「それは」または「それは持っている」などを参照しHow to Use Its and It's

user3791372 07/27/2017.

質問のタイトルに答えて: "あなたはTDDで"本当の "コードを書くのはいつですか?"答えは「ほとんどない」または「非常にゆっくり」です。

あなたは学生のように聞こえるので、私は学生に相談するかのように答えます。

あなたは、多くのコーディング「理論」と「テクニック」を学ぶつもりです。 彼らは高価な学生コースで時間を過ごすのに最適ですが、半分の時間で本を読むことができないという利点はほとんどありません。

コーダーの仕事はコードを生成することだけです。 本当にうまくいくコード。 それでコーダーはあなたの心の中、紙の上、適切なアプリケーションの中などでコードを計画し、コーディングの前に論理的および横方向を考えて、事前に可能性のある欠陥/穴を回避する計画です。

しかし、適切なコードを設計できるようにアプリケーションを破壊する方法を知る必要があります。 たとえば、 Little Bobby Table (xkcd 327)について知らなかった場合、データベースを操作する前に入力をサニタイズしていない可能性があります。そのため、データをそのコンセプトで保護することはできません。

TDDは、コードを導入する前に間違っている可能性のあるテストを作成することで、コードのバグを最小限に抑えるよう設計されたワークフローです。 アプリケーションを終了したら、テストを実行してブームを起こすと、うまくいけばテストでバグが見つかるはずです。

TDDは、ある人が信じるように、テストを書いたり、最小限のコードで渡したり、別のテストを書いたり、最小限のコードで渡したりするのではなく、自信を持ってコードを書く方法です。 このリファクタリングコードをテストに使うためには理想的ですが、新しい機能を追加してコードを書く方法を学んでいるので気分がいいので、学生の間で素晴らしいコンセプトです...

このトラップを倒して、それが何であるかをコーディングするあなたの役割を見てはいけません。コーダーの仕事はコードを生成することだけです。 本当にうまくいくコード。 さて、あなたはプロのコーダーとして時計に乗っていることを忘れないでください。100,000のアサーションを書いても、クライアントは気にしません。 実際、本当にうまい。

5 comments
3 johnny 07/25/2017
私は学生の近くでさえないが、私は読んで、良いテクニックを適用し、プロフェッショナルになろうとする。 そういう意味で、私は「学生」です。 私はそれが私の方法であるので、基本的な質問をするだけです。 私は自分が何をやっているのか正確に知りたい。 問題の中心。 私がそれを得なければ、私はそれが気に入らず、質問をし始めます。 私はそれを使うつもりならば、なぜ私が知る必要があります。 TDDは、何かを作成し、思考するために必要なものを知っているような、いくつかの点で直感的には良いようですが、その実装は理解しづらいものでした。 私は今、より良く把握していると思う。
4 Sean Burton 07/27/2017
それらはTDDのルールです。 あなたは自由にコードを書くことができますが、3つのルールに従わなければTDDをやっていません。
2 user3791372 07/27/2017
一人の "ルール"? TDDは、宗教ではなく、コード作成に役立つ提案です。 非常に多くの人々が非常に奇妙なアイデアを遵守しているのは悲しいことです。 TDDの起源さえも議論の余地があります。
2 Alex 07/28/2017
@ user3791372 TDDは非常に厳密かつ明確に定義されたプロセスです。 たとえ多くの人が「プログラミングしているときにいくつかのテストを行う」ということだけを考えていても、そうではありません。 ここで用語を混同しないようにしましょう。この質問は一般的なテストではなく、プロセスTDDについてです。

Related questions

Hot questions

Language

Popular Tags