TDDネタ再燃？

seki at druby.org @m_seki

@akiyama924 じゃあ。そこは私と気にしてるところが違いますね。つーか、レガシーコードも好きじゃないんだよな。

あきやま🍠 @akiyama924

@m_seki とても重要と考えています。「レガシーコードとはテスト用のコードがないコードだ」とかいう本がありましたよね。

あきやま🍠 @akiyama924

@m_seki 「TDDがあるからテストは要らない」という人は少ないと思いますが「TDDがあるからテスト用のコードはそれ以上書かない」という人は多いのでは。

seki at druby.org @m_seki

@akiyama924 ふつうすぎてないかもしれませんね。わたしは何度もそう講演しましたが。 逆にTDDあるからテスト要らないとかいうへんなページは見たことあるなあ。本もありそう。むかつく。

seki at druby.org @m_seki

@akiyama924 文法エラーを見つけるのはテストでしょうか？リンクエラーはどうだろう。

あきやま🍠 @akiyama924

@oota_ken そのケースでも、お客様は、テストコードはつかわないし文句も言ってはこないのでは？ この想像通りならやはり開発者の優先度は下がるので同じように思います。

あきやま🍠 @akiyama924

昔も、みかままさんに、「TDDはテストじゃなくてプログラミングのためのもの」と言われたことがあったけど、相変わらずそこが腑に落ちていないということかも。

makoto yonezawa @vestige_

@akiyama924 さんからみて意味のないテストコードがあったのと、メトリクスとして使われたことに疑問っていうか、TDDに価値を感じないことがあったんですね。なんとなく昨日の発言がみえてきました。

あきやま🍠 @akiyama924

@m_seki そうかなぁ？そういった「実装のためのTDD→コーディング→保守用のテストコード」というプロセスを明示している書籍ありますか？

seki at druby.org @m_seki

@akiyama924 @t_wada さんの講演でTDDの表明の足跡の方のテストコードを整理する話を聴いたことがあります。また、TDDとは別に、テストコードを書いてるんじゃないですかね。ふつうは。

あきやま🍠 @akiyama924

そういわれて見直すとメリットっぽくない書き方ですね。 @sakata_akinori: @akiyama924 1.～6.ってメリットなんですか?

あきやま🍠 @akiyama924

そして、@m_sekiさんのように後からテストコードを整備される方は少数派ではないかなとも（実際に私は他に知りませんし）。

あきやま🍠 @akiyama924

プログラムコードは納品物ですが、一般にテストコードは納品物ではありません。開発者は、納期のプレッシャーがあるので、先にテストコードを書くというルールは@oota_kenさんのように、確固たる信念がないと難しいのではないかなぁと思ったのです。

あきやま🍠 @akiyama924

不思議に思った私は、テストコードを読みました。そうしたら、そのプロジェクトでは、C1カバレッジがTDDのメトリクスとして測られていたのですが、それを100%に持っていくことが目的のようなテストコードだったのです。

あきやま🍠 @akiyama924

月日は流れ、テストフェーズに移りました。そうしたら、TDDで先にテストコードを書いたチームのコードの方が「こんなバグが」といったようなバグが多く出たのです。

あきやま🍠 @akiyama924

私は「いいですよ」といい、いくつかのチームは、TDDで先にテストケースを書きました。そしていくつかのチームはコードを書いてからテストコードを書きました。

あきやま🍠 @akiyama924

私の質問関連の思い出としてはこんなのがあります…。とあるプロジェクトで「TDDしましょう」ということになりました。そのフォロー会であるチームのリーダの方が「テストを先に書くことはできていませんが、テストコードはちゃんと後から書いていますのでいいですか？」という質問があったのです。

あきやま🍠 @akiyama924

TDDに嫌な思い出はないです。

miwa @miwa719

いろんな立場の人がいるけど、みんないいものを作りたいのは一緒。TDDもそういった目的を実現する手段の一つだと思ってます。TDDは最近知ったけど、QAとかカスタマー的なテスト屋の立場にいるものとしては、うちらも頑張る！という気持ちになります。 #toteka

seki at druby.org @m_seki

@yoshiori よし。泣かす。（嘘

ヨシオリX @yoshiori

@m_seki それなら朝までつきあいます！！

seki at druby.org @m_seki

@yoshiori プログラミングの姿勢的にTDD気に入らないんところあるんですけど、そういう話題でつきあってくれますか？

あきやま🍠 @akiyama924

@m_seki TDD好きじゃなかったのですね。リファクタリングやどこまでTDDで検証するのかについては手持ちの本を読んでからにします。今日は寝ます。おやすみなさい。

seki at druby.org @m_seki

@akiyama924 いやこれはTDDに出てこないです。なのでTDD好きじゃないんです。リファクタリングをするってことは、壊さないように実装を洗練させたいんだけど、実装が洗練されたことを確かめるにはどうするかについて抜け落ちているって話です。

@oota_ken

@akiyama924 ええと僕は少なくとも後から入れる方法はムリです、契約自体が完全に正しい保証がないので具体的な値をいれてテストしながら契約と実装、テストの三者をこぎざみに修正していくのです。遠まわりのように見えますが経験上これが一番の近道です。