TDDが機能しない

TDDは機能しません。

そう？ 変です。 それはいつも私にとってうまくいった。

しかし、 新しい研究ではそうでないことが示唆されています。

新しい研究？

はい、数年前に実施された別の研究の手順を繰り返す綿密な研究。 両方とも、TDDが機能していないことを示しました。 ブラインド分析を使用して、いくつかの場所で新しい研究が行われました。 説得力があります。

著者は説得力があると考えていますか？

著者は新しい研究を推奨しています。 しかし、彼らはおそらくささやかなものです。 結果はかなり説得力があります。

結果は何ですか？

調査によると、TDDについての主張は誤りです。 TDDは開発速度を向上させません。 欠陥の数を減らしません。 より良いコードを書くことは役に立ちません。

とても奇妙です。 TDDによって速度が向上し、コードと精度が向上するように思えます。 私に同意する他の人を知っています。 この研究が別の結論に達したのは驚きです。

それにもかかわらず。 DHHは正しかった。 TDDはデッドです。

うーん さて、研究の著者たちは正確に何をしましたか？ 彼らはどのようにしてこの結論に達しましたか？

知りません 私は研究があったことだけを知っています。

この研究についてどうやって知りましたか？

彼についてブログで読んだ。 最後に、著者はTDDを再考したと述べました。 彼はTDDが機能すると信じていました。

さて、まあ、この研究を見てみましょう。 うーん...はい、彼らはTDDとTLDを比較したと言っています。

TLDとは何ですか？

LAST開発をテストします。 これは、 コードを書いた後に単体テストを書くときです 。

よくここに！ 調査によると、最後にテストを書くのが最適です！

うーん いいえ、これは研究が示したものとはまったく違うようです。 実際、有意差はないことが示されました。

まあ。 つまり、コードを記述してからテストを記述した場合、これはTDDよりも悪くありません。

まあ、そうでもない。 いずれにせよ、これは研究が話していることではありません。 その過程で、TLDサポーターは「小さな断片」で作業するように求められました。

小片で？

はい TLDの支持者は、少量の実動コードを作成してから、いくつかのテストを行いました。

うん、わかった。 つまり、彼らは10分間実稼働コードを書き、その後10分間でテストなどを書きました。

まあ多分。 しかし、ここでは、すべての参加者がTDDトレーニングを受けたと言っています。 そして、それらの一部は、TLDを小さなピースで作成するように依頼されました。

うん。 わかった まあ、私の声明はまだ真実です。 彼らは製品コードを書き、それからユニットテストを書きました。 そして、それは何にも影響しませんでした。

質問をしましょう。量産コードの後で、単体テストをどのように作成しますか？

いくつかのテストに合格するのに十分な量の小さな実動コードを作成し、それらのテストを作成します。

いくつかのテストを満たすために必要なコードの量をどのように理解しますか？

いくつかのテストを紹介し、それらを満たすコードを作成します。 次に、テストを作成します。

TDDのスキルはありますか。 そのような考え方はあなたには明らかでしょう、そうでしょうか？

うーん...うーん...私はあなたの意味を理解していると思います。 TLDはTDDを作成し、すべてを逆の順序で実装しました。

そうだね。 細かく作業するには、事前にテストを提出する必要がありました。 テスト可能な製品コードを作成できるようにします。

たぶん、この研究では、何が意図されているかを調べなかったのかもしれません。

彼らは、TDDプロセス自体ではなく、テストの記述順序を調査しようとしたと思います。 変数の数を減らすために、変数をすべて取り除きました。 TLD参加者は、 短いサイクルでTDDプロセスを使用するように強制されました 。 そして、これにより参加者はコードに取り組み、事前にテストについて考えるようになりました。

わかった たぶん。 それでも、これらのTLD は最後にテストを作成しました 。 テストでは、少なくとも最初にテストを書く必要はないことが示されました-少なくとも作業が短いサイクルで行われる場合。

もちろん。 TDDの有効性は、サイクルのサイズに依存しますが、テストの優先度にはそれほど依存しません。 サイクルの長さの短縮につながるため、事前にテストを作成します。

つまり、この研究は、短いサイクルで作業する人は事前にテストを書くことを心配する必要がないかもしれないことを示しました。 主なことは、短いサイクルで作業を続けることです。

公正な結論のようです。 しかし、ここを見てください。 参加者はボウリングゲームの問題に取り組みました 。 これは非常に小さなタスクです。 彼らは、すべてについてのすべてのために、彼らはわずか3時間かかったと言いました。

これは重要ですか？

もちろん。 事前にテストを書くことの利点は規律です。 事前にテストを記述することで、サイクルが拡大するのを防ぎます。 長期間にわたって高いカバレッジを維持します。

はい。ただし、サイクルを短く保つのに十分な規律がある場合、調査によると、いつテストを書くかは問題ではありません。

はい、でもそれ以上です。 この研究は、TDDのトレーニングを受けた人々のグループを取り上げて、開発サイクルの維持やテストの記述順序の変更のみを含め、すべてを行うように指示した場合、3時間のプログラミングでは違いに気付くことは不可能であることを示しています。

うん。 うん。 研究はそれを示しています。

したがって、実際には、研究は区別せずに区別しました。

えーと、彼は違いを見つけられなかったので、おそらくそうです。

つまり、この研究ではTDDが機能しないことが示されていませんでしたか？

いいえ、おそらくそうではありませんでした。

それは何を示しましたか？

研究を読まずに研究の結論を解釈することは不可能であることを示したと思う。