きょんさんの資料, 自動テストの誤解とアンチパターン 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は自殺している
