きょんさんの資料, 自動テストの誤解とアンチパターン in 楽天 Tech Talkを読んでもやもやしたところをつらつらと。
-
因子水準
- ググると実験計画法が出てくる
- 自由度的な意味で捉えればOK？
-
「統合テスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」
- 主客逆では？
- これらがないと作れない、というのが僕の理解。いまんとこ。
- スライド P.18で行っていることも↑と同じことを言われているんだと思うんだけれども。。。
- 主客逆では？
-
「効果的な自動テストとは何かを考えないと『自動化対象外と協調したテスト設計をおろそかにする』」
- 自動テストを考える際に得られるドメイン知識やアーキテクチャ知識が、自動化対象外のテスト設計にも好影響を及ぼす、といいたい？
- だとすると、「統合テスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」という言葉の落ち着き先がここ？
-
「どうやってテストとプロダクトを綺麗にするか」「TDD用のリファクタリング」
- いかにTDDを自殺させないか、ということだとは思うけれど、具体的にどうすればいいんだろ？？
- TestDouble無しにコンポーネント統合テストは書けないし、単体テストも本質的にしんどい。
- 「使うな」ではなく、アプリケーションドメインの劣化コピーを量産しないために、という話なのだろうけれど。
-
「(TDDにより)プロダクトコードからアプリケーションドメインが漏れたり、埋め込まれないことが有る」
- 漏れだすのは分かる。でも、テストコードのせいで埋め込まれないってのはどういう場面？？
- それだとプロダクションコードとして未完成になるのでは？？
- 小さいレベルだと、アプリケーション知識をプロダクションコードから取り除くことは有るのは分かる
- でも、その時は、取り除かれたコードの上位のレイヤにアプリケーションドメインが集約されるのでは？
- DDDでいうところのインフラ層にコードを落としこんでいるのでは？
- 漏れだすのは分かる。でも、テストコードのせいで埋め込まれないってのはどういう場面？？
-
「Why Fail」
- なんで失敗した（する）んだろう、という疑問がもやもやしてしまった
- P.69 あたりを対偶取ると・・・
- スキルが高いプログラマーで、属人性上等でハイスピードでコードを書くからにはTDDはそこまで効果的でない
- テストコードをドキュメントとして扱わず、ただのコードとして扱ってしまい、別でせっせとドキュメント整備したりすると、やっぱあんまりよろしくない
-
「統合テストの自動化はその前段階にかかっている」のはそのとおり。
- 前提となる知識なしに自動化すると、「お前は一体何と戦っているんだ」になる
-
「自動化のROI」ばっか考えると、自動化（を深く考えること）によって得られるReturnを見落とすよね、というのは忘れがちなのでありがたい
- 自動化することって、暗黙知を形式知に落としこむ一つの手段でも有るんだなぁ、と個人的には腹落ち。
- BRMS: Buisness Rule Management System
- レゾンデートル： 存在価値
- プロダクションコードにアプリケーションドメインは入っていくもの
- 理想はプロダクションコードにアプリケーションドメインが完全に表現されているはず
- DDDとかもこの系統（だよね？）
- 一方、テストコードもまたアプリケーションドメインから見た使い方を表現しているはず
- 必然、テストコードにはアプリケーションドメインが漏れだし、劣化コピーされる
- TestDouble, Fake
- ドメインを重複させたり、似非ドメインを量産し始めたTDDは自殺している
因子水準はテストのパラメータのことで、変数自体を因子、実際の入りうる値を水準と言います。同値分割や境界値分析では対象因子の水準を決定することです。テスト技法ドリルとか秋山さんのJaSSTの資料くらいにはよくでてくるはず。
「統合テスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」の主客が逆だと言われればそうなのかもしれないですが、僕は「テストをしながら勉強する」というのが普通なので「いまそういうスキルがないから自動統合テストは無理」だという判断はあまりしないです。なのでこの順序が自身の経験としてあいます。
「TestDouble無しにコンポーネント統合テストは書けないし、単体テストも本質的にしんどい。」というのが現状のxUnit, xSpecに縛られているだけの話だと思います。僕は自作のテスティングフレームワークで、テストケースの依存関係で表現するようなテスティングフレームワークをつくっていますね。
「漏れだすのは分かる。でも、テストコードのせいで埋め込まれないってのはどういう場面？？
それだとプロダクションコードとして未完成になるのでは？？」
例えばテスタビリティを気にしすぎて、アプリケーションドメインとは異なる依存関係になることがあります。ソリューションの都合によって乖離することは(特に永続化の付近で)多々ありますが、テストコードによってそれが増幅することがあります。
他にはリファクタリングが十分ではないときも当てはまります。
「なんで失敗した（する）んだろう、という疑問がもやもやしてしまった」
p69においては、低スキルな人がTDDしていてしかもスキル向上があまりないと、バグを埋め込む可能性が「プロダクトコード」と「テストコード」によって2倍になっています。
Adaコンパイラなどの例は、TDDをとりいれたときに自分たちの設計プロセスを変容させてしまったことが問題になっています。