ロンドン学派とかについて語るなら「Googleのソフトウェアエンジニアリング」も読んでおいて損は無い。古典学派に行き着くと思うから。
古典学派だのロンドン学派だの、テストの書き方で宗派が分かれるのは面白い。結局は実装の詳細に踏み込みすぎて自爆するのがお約束
いや古典学派はロジックと入出力をテストしろ、Mockが必要なコードを書くな、だったと思うのだが。例えば f(){a=DB.getA();処理～}があったらDBをMockにするんじゃなくてa=DB.getA();b=fx(a);と分けてfxをテストすればMockは不要になる
結果自分が古典派だったと後から知っただけで、本人たちは派閥で別れようと思って別れている訳では無いです（みんなそうだよね？）
“単体テストが備える性質3つ：少量のコードを検証、実行時間が短い、隔離された状態で実行。古典学派（極力モックを使わない。実DBを使う）とロンドン学派（モックを多用して、まずは動くシステム一式を作成）”
きょうみある
“TDDの歴史的な話はめちゃくちゃ面白かったのと「テスト駆動開発」の付録Cにてt-wadaさんが解説してくれているのでまだ読んでない方はぜひ読んでください。” ありがとうございます
モック絡んでくるとややこしくなるよね<単体テストとして正しいのか
壊れやすいテストとは？ 「単体テストの考え方/使い方」(古典学派)と「実践テスト駆動開発」(ロンドン学派)を読んで考える
ロンドン学派とかについて語るなら「Googleのソフトウェアエンジニアリング」も読んでおいて損は無い。古典学派に行き着くと思うから。
古典学派だのロンドン学派だの、テストの書き方で宗派が分かれるのは面白い。結局は実装の詳細に踏み込みすぎて自爆するのがお約束
いや古典学派はロジックと入出力をテストしろ、Mockが必要なコードを書くな、だったと思うのだが。例えば f(){a=DB.getA();処理～}があったらDBをMockにするんじゃなくてa=DB.getA();b=fx(a);と分けてfxをテストすればMockは不要になる
結果自分が古典派だったと後から知っただけで、本人たちは派閥で別れようと思って別れている訳では無いです（みんなそうだよね？）
“単体テストが備える性質3つ：少量のコードを検証、実行時間が短い、隔離された状態で実行。古典学派（極力モックを使わない。実DBを使う）とロンドン学派（モックを多用して、まずは動くシステム一式を作成）”
きょうみある
“TDDの歴史的な話はめちゃくちゃ面白かったのと「テスト駆動開発」の付録Cにてt-wadaさんが解説してくれているのでまだ読んでない方はぜひ読んでください。” ありがとうございます
モック絡んでくるとややこしくなるよね<単体テストとして正しいのか