@ryohei_nakazawa との TDD における品質の考え方ツイートまとめ

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ この件を読んでるナウ。togetter.com/li/679996?page…

ますごん @ymasuda_

@ryohei_nakazawa TDDと自動テストって、文脈が近いけど非なるものではないか。TDD はコーディングに近いところにあり、これまでのデバッグ実行のプロセスに近い部分だと。自動テストは単体テストも結合テストも自動化できる可能性はあるが TDD とは異なるって感じ。

ますごん @ymasuda_

@ryohei_nakazawa さらにメトリクスは結合レベルくらいじゃないと難しいんじゃないかと。最近の開発スタイルはコーディングしながらデバッグ実行して確認してる。どこまでコーディングで、どこからテストか線引きしにくい。丁寧な人ほど丁寧にデバッグしてテストでバグが出にくい。

ますごん @ymasuda_

@ryohei_nakazawa つまり、TDD も同様でバグ件数などのトラッキングは難しいだろうというのが俺の意見で、ついでに言うと TDD はコーディング・デバッグの一つのスタイルで、強制するもんではないのかな、って気がしてる。

ますごん @ymasuda_

@ryohei_nakazawa （承前） だからテスト書く密度、線引きは人それぞれ。便利さに共感すれば自ずと広がる。 、、、ってのはヒヨった意見かな。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ うん、TDDのredはコーディング中のデバッグと同じかと。つまりメトリクスで欠陥密度がうんぬん、品質指標がどうのこうの、の世界とは切り分けると。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ この際、一番小さいユニットテストレベルの品質をどう考えるか。開発者任せにするのか、第三者的にユニットレベルの品質保証を必要とするかで、変わってくる。 実際問題、うちらの目の前の開発だとどうなの？って話は、議論の価値ありかな、と思って、メンションしたwww

ますごん @ymasuda_

@ryohei_nakazawa 単体テストの品質保証は、バグ密度、収束率 などはあまりフィットしないというのは先のツイートから一貫する俺の意見。じゃあ、どうするかというと、テストケースの仕様網羅率と、それがテストされているかの完了評価かな、と。（続く）

ますごん @ymasuda_

@ryohei_nakazawa （承前）なので、設計書は、テストケースが作りやすいように書かなければいけないし、網羅していることをレビューできるものでなければいけない。

ますごん @ymasuda_

@ryohei_nakazawa 一方で、コンポーネント化しているものは、JUnit でクラス単体（コンポーネントに閉じた品質）は必要だと思う。先の考えが成立するのは、機能は コンポーネントの組み合わせという前提があるからこそ、成立する考えかもしれない。

ますごん @ymasuda_

@ryohei_nakazawa コンポーネントが適切に切り出せていないことを前提に考えてしまうから、悩ましい問題が出てくるように思う。 設計と品質は表裏一体なので、どういう設計するから、どういう品質保証（テストなど）が必要か、という話は切り離せないというのは俺の持論。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 設計とテストが表裏一体という意味で激しく同意。基本な考え方として、(対応する)設計通りかどうかを確認するのがテスト。さて、ここで、コンポーネントレベルの仕様が明文化されているケースとされていないケースに分けて考えてみたとき、どっちをイメージしてる？

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ ちょっとTDDはさておき、現実的な話として、コンポーネントレベルの仕様が開発者の頭の中にしかないとすると、その時点で品質「保証」はないな、理屈として。ただ現実は.........知っての通りかと。適切にコンポーネントを切り出せていないという話に繋がるが、

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ なおさら前提が複雑になるのでもっと単純化して、書いたとおりに動くかどうかのユニットテストと、実現すべき機能が実現できているかのユニットテストは、分けて議論したほうがいい気がしてきた。今日は寝る。また、思い立ったら続きをw

ますごん @ymasuda_

@ryohei_nakazawa もろもろ設計は必要とした上で、設計書にどこまで書くのかという問題はある。ただ設計書に書いた内容がテストケースとしてレビュー可能だとは思う。その先は個人の責任と裁量。個人が自分の責任を果たすための確認のテストをどうするか。（続く）

ますごん @ymasuda_

@ryohei_nakazawa （承前）結果を残すか、結果をレビューするか、定量的評価を必要とするのか。もしかするとテストする必要があるのかという部分から議論が必要か？まぁ、そこは必要ということでいいと思うんだが。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 短文ムズい。「もしかすると(個人が確認する)テストの必要」をデバッグの一貫とすれば議論の余地なしかと。この流れでいうと、ユニットテスト(≒最小単位なﾃｽﾄｲﾒｰｼﾞ)を個人の確認と位置付けるのか、明確な テストと位置付けるのか、という部分がポイントで、

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 前者ｲﾒｰｼﾞなら、最初にyouが言ってた、「メトリクスは結合テストから」は理解。オレの脳内は、後者であるべきなのは分かっていながら、なし崩し的に前者になっている場面だった。んま、人によって感じかたは異なるだろうが。。。いちいちそこまで考えねー、的なwww

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 話を戻すと、TDDは（プログラミングの）ひとつのスタイルっていうのは同意見。強制NG。 ただ、この話、ここで終わらず。それは、個人的に、テストファースト思想自体が、開発のエンジニアリングのスタイルにまで繋がる話だと思うから。従来型の進化に活かすネタになるかと。

ますごん @ymasuda_

@ryohei_nakazawa 整理すると、①TDDの位置付け、②最小単位の「テスト」（デバッグじゃない）の粒度、③最小単位のテストの定量的評価、④設計書の粒度・記載レベル、⑤定量的評価を必要とするテストの粒度、⑥TDDをプロジェクト全体に適用するか、が出てきたトピックかな。

ますごん @ymasuda_

@ryohei_nakazawa 個人的には、②・④あたりのコンセンサスを取るのが難しいかな、と。

ますごん @ymasuda_

@ryohei_nakazawa テストファーストはいいと思う。Wモデルにつながる話でもあるし。システム（大小問わず）の処理が終わった時点でどうなっているか、が仕様であり、その確認をするのがテスト。テストケースを作成することで設計で曖昧にされていた仕様が明確になるのはよくあるし。

ますごん @ymasuda_

@ryohei_nakazawa ホストの不自由な開発環境を前提とした単体テストと、最近の IDEバリバリな開発環境を前提とし単体テストって、若干ニュアンス変わってくるような気がする。共通して必要な要素と、あの環境だからこそ必要だった要素とがあるのでは？とか思ったり。

ますごん @ymasuda_

@ryohei_nakazawa 俺を含め「単体テスト当然だよね」 という空気はあるが、どう考えてそう言ってるのか聞いてみたいね。まぁ、そんなに深く考えてねぇってのが多そうだが。考えれば考えるほど、上流～下流まで含めた深い理解がないと難しい。たいていは深く考えてないってことだな。