深夜のテストTL

@skn9x

TDD 関連の話で思ったんだけど、djUnit とかのアプローチって、あれ TDD とは相性悪いような気がした。コードの内部事情にべったりだし。

@t_wada

何人が TL 上で TDD のことを議論しているんだろう。すごいな。興奮する。

@skn9x

TDD は設計向きだという話は、なんか納得しちゃう。大まかなロジックが確定した設計書渡されて TDD できなかった経験あるし。

@cactusman

@yoshiori だから、動作確認するのがめんどくさい、というのでもテストファーストじゃなくプログラミングファーストでもよくならない？ *Tw*

@ukstudio

個人的にTDDの重要な点は「フィードバック」だと思ってるので、@yoshiori の「 print 文で目で確認するのがメンドイからコンピュータでも判るように 真偽で確認する」ってのは一理ある気がするなぁ

@skn9x

@cactusman 不安を取り除くためだけなら、プログラミングファーストで十分？　テストファーストにする利点はなんだろう。

@cactusman

@skn9x あとからでもテストコードは書けるわけで、じゃぁ、なんでテストファーストなの？というところが大事じゃないかと思ってる。 *Tw*

@skn9x

見方を変えれば「テスト先に書いたってイインダヨ」的な視点を持ち込むこと自体が有意義なのかもしれないけど。プログラムとテスト、ぱっとわかりやすいほうを先に書くのが良いんだろうか。

@nsiena

@nsiena TDDが目指してる品質の向上ってのは。「コードの品質」でなく、「(詳細)設計の品質」だと理解してる。言い換えるなら、欠陥試験でなく、レビュー・仕様検証。

Ayumu AIZAWA @ayumin

@ukstudio TDDの重要な点はフィードバックというのには同意。次のアクション（それが実装であれリファクタリングであれ）を起こすための支えになるフィードバックを十分に早く、必要な粒度で提供できる環境が重要ですよね

さ↑ぼてん↓（さぼ福）🌵 @cactusman

@yoshiori 自分は、テストコードを先に書く＝オブジェクトや関数の使い方を定義する、というふうにだと考えています。 *Tw*

Koichi ITO @koic

TDD による品質の向上は、進化的設計をすることによる *副作用* だと考えています。

@ayumin

前プロジェクトではCIを試みた結果、スローテスト問題にぶちあたって困った

ゆーけー @ukstudio

@ayumin そうですね。大きなところから初めようとすると「まず何をしたらいいのん?」状態になるので、小さいところから始めてフィードバックを元に次のアクションを決めるってのが重要だと思います。

わいさかき🥞 @ysakaki

会社としての品質保証はプログラムのテストより大きい概念。私が言っているテストの品質、はプログラムのテストの話です。

さ↑ぼてん↓（さぼ福）🌵 @cactusman

@yoshiori テストコードを先に書くことで明確になると思いますが。 *Tw*

ヨシオリX @yoshiori

やっと最近、去年の富山でひがさんと和田さんに言われた「TDD!=テストファースト」が頭じゃなくて心で理解出来るようになってきた。

Takuto Wada @t_wada

動作を確認する、というのと、動作を確認し続ける、ということの違いだと思います。自動化された self-checking なテストは確認を無人で繰り返すことができるから、CI などで「自働化」できるわけですよね。TDD の話というより自動化の話ですね。

ヨシオリX @yoshiori

@cactusman うん、でもそれ、テストファーストの話しだよね?? 今、俺はテスト駆動開発での「品質」に対する期待値的な感じ方の話しをしていたんだ

ゆーけー @ukstudio

実装で悩んだらとりあえずテストを書くようにしてる。大体それで解決する。

MOROHASHI Kyosuke @moro

@ayumin スローテスト問題は、問題は問題で困ったちゃんだけど、移動したあとのボトルネックなのでそこは喜んでいいと思う。喜んで、心の力をためて、問題と戦う。

Ayumu AIZAWA @ayumin

「テスト再入門勉強会」をやろうやろう

goyo @goyoki

変な感じが。TDDのテストと仕様書のトレーサビリティは普通あまり考慮されてないと思う。仕様の検証をしたいなら、仕様分析に基づいたテストコードの再構築がいずれ必要になるんじゃないかな、と感じる

Yasuharu Nakano @nobeans

自分の場合はテストファーストじゃなくて、並行or後追いでテストを逐次作っていく方式でも、十分不安が払拭できるなぁ。設計は大体概要を頭の中で描いてから手をつけるし。頭の中に収まらないような大きさの画が必要な場合は、UMLスケッチを描いてる。あ、これTDDじゃないや。

Ayumu AIZAWA @ayumin

テスト再入門勉強会実行委員 @ayumin @ukstudio