Growing Object-Oriented Software, Guided by Tests(goos_jp)読書会 : Recent Changes
http://devtesting.jp/goos/?c=recent
Growing Object-Oriented Software, Guided by Tests(goos_jp)読書会 Recent Changes
ja
Copyright (C) devtesting-ja
2012-09-23T05:39:22+00:00
-
担当割当表/Part4
http://devtesting.jp/goos/?%E6%8B%85%E5%BD%93%E5%89%B2%E5%BD%93%E8%A1%A8%2FPart4
2012-09-23T05:39:22+00:00
@@ -42,15 +42,15 @@
!Chapter 23: テスト診断室(Test Diagnostics)
||!見出し||!担当||!完了||
-||[[失敗させるための設計|member/Chapter23/Design to Fail]]||||||
-||[[小さくて狙いが絞られており、うまい名前がついているテスト|member/Chapter23/Small, Focused, Well-Named Tests]]||||||
-||[[説明的なアサーションメッセージ|member/Chapter23/Explanatory Assertion Messages]]||||||
-||[[マッチャーで詳細を際立たせる|member/Chapter23/Highlight Detail with Matchers]]||||||
-||[[自己言及する値|member/Chapter23/Self-Describing Value]]||||||
-||[[仕込まれたことが明らかな値|member/Chapter23/Obviously Canned Value]]||||||
-||[[トレーサーオブジェクト|member/Chapter23/Tracer Object]]||||||
-||[[エクスペクテーションを満たすことを明示的に確かめる|member/Chapter23/Explicitly Assert That Expectations Were Satisfied]]||||||
-||[[診断はファーストクラスのフィーチャ|member/Chapter23/Diagnostics Are a First-Class Feature]]||||||
+||[[失敗させるための設計|member/Chapter23/Design to Fail]]||||9/23||
+||[[小さくて狙いが絞られており、うまい名前がついているテスト|member/Chapter23/Small, Focused, Well-Named Tests]]||||9/23||
+||[[説明的なアサーションメッセージ|member/Chapter23/Explanatory Assertion Messages]]||||9/23||
+||[[マッチャーで詳細を際立たせる|member/Chapter23/Highlight Detail with Matchers]]||||9/23||
+||[[自己言及する値|member/Chapter23/Self-Describing Value]]||||9/23||
+||[[仕込まれたことが明らかな値|member/Chapter23/Obviously Canned Value]]||||9/23||
+||[[トレーサーオブジェクト|member/Chapter23/Tracer Object]]||||9/23||
+||[[エクスペクテーションを満たすことを明示的に確かめる|member/Chapter23/Explicitly Assert That Expectations Were Satisfied]]||||9/23||
+||[[診断はファーストクラスのフィーチャ|member/Chapter23/Diagnostics Are a First-Class Feature]]||||9/23||
!Chapter 24: テストの柔軟性(Test Flexibility)
||!見出し||!担当||!完了||]]> -
member/Chapter23/Diagnostics Are a First-Class Feature
http://devtesting.jp/goos/?member%2FChapter23%2FDiagnostics+Are+a+First-Class+Feature
2012-09-23T04:12:40+00:00
@@ -0,0 +1,2 @@
+TDD のサイクル Red Green Refactoring に report を入れて、 Red Report Green Refactoring にするとよいと思う。
+一ヶ月後にその箇所をだれかがいじろうとしても、なにをやっているかわかりやすくなる。]]> -
member/Chapter23/Explicitly Assert That Expectations Were Satisfied
http://devtesting.jp/goos/?member%2FChapter23%2FExplicitly+Assert+That+Expectations+Were+Satisfied
2012-09-23T04:10:25+00:00
@@ -0,0 +1,4 @@
+(mock の)expectation と assertion が両方あるようなコードでは、mock したメッセージパッシングが失敗していることが原因でテストが落ちていても、さきに assertion が確認されるので、エラーがわかりにくくなる。
+
+mock の呼出確認をするメソッドをすべての assertion の前に呼ぶとその時点で落ちるのでわかりやすくなる。
+(コメント:js のモックライブラリなどでは必須)]]> -
member/Chapter23/Tracer Object
http://devtesting.jp/goos/?member%2FChapter23%2FTracer+Object
2012-09-23T04:07:40+00:00
@@ -0,0 +1,7 @@
+コードのなかで、オブジェクトがどのように持回されているかがわかる。 Object Canned Value の一種だ。
+
+なんの振る舞いも持たないが、テストが失敗したときに自分の役割を説明してくれる。
+(コメント:私は参照されないはずの引数を ruby で扱うとき、 :not_used_value のようなシンボル(文字列とだいたい等価)を渡している。こうするとまずメソッド呼出は成功しないので、 nil より Error のときになにがどこで呼ばれているのかわかりやすい。)
+
+jMock ではモックオブジェクトに名前をつけることができる。
+(コメント:モックに名前をつける機能はほとんどのモックライブラリが提供している。jMock は同じオブジェクトのモックがあって名前がついていないと警告を出してくれるらしい)]]> -
member/Chapter23/Obviously Canned Value
http://devtesting.jp/goos/?member%2FChapter23%2FObviously+Canned+Value
2012-09-23T03:59:29+00:00
@@ -3,7 +3,7 @@
本番で得られるだろう値とはあきらかにことなった値をいれることができる。それがコードを壊さなければ、だが。
チームが本番でなにが入るかの合意ができていれば、異なる値はすぐにわかるようになる。
-- Integer.MAX_VALUE
-- 負の値
-- 1970 年の日付
-- 5ケタの ID がはいるところに、3ケタの値。
+* Integer.MAX_VALUE
+* 負の値
+* 1970 年の日付
+* 5ケタの ID がはいるところに、3ケタの値。]]> -
member/Chapter23/Self-Describing Value
http://devtesting.jp/goos/?member%2FChapter23%2FSelf-Describing+Value
2012-09-23T03:56:11+00:00
@@ -0,0 +1,5 @@
+アサーションに使う値に詳細をくみこもう。
+アアーションにもっと詳細をつけくわえたいと思ったなら、もっと失敗を明確にできる兆候だ。
+
+- 文字列はなんのつもりで使っているのかわかるものにする
+- インスタンス生成時に toString をオーバライドして自己説明する値を持たせる。]]> -
member/Chapter23/Highlight Detail with Matchers
http://devtesting.jp/goos/?member%2FChapter23%2FHighlight+Detail+with+Matchers
2012-09-23T03:52:55+00:00
@@ -0,0 +1,3 @@
+assertThat とカスタムマッチャを使おう。どの値が興味のあるものであるかがわかりやすくなる。
+
+(コメント: RSpec のカスタムマッチャの威力をさいきんしみじみと感じている。DRY になるし、テスト結果の可読性がとても上がる。)]]> -
member/Chapter23/Explanatory Assertion Messages
http://devtesting.jp/goos/?member%2FChapter23%2FExplanatory+Assertion+Messages
2012-09-23T03:47:46+00:00
@@ -0,0 +1,3 @@
+JUnit の最初の引数はアサーションに失敗したときに表示されるメッセージであるが、この機能はもっと使われるべきだ。
+
+たとえばどの値がマッチングされているかを記しておけば、テストの失敗メッセージをみてすぐにどの機能がおかしいのかがわかる。]]> -
member/Chapter23/Small, Focused, Well-Named Tests
http://devtesting.jp/goos/?member%2FChapter23%2FSmall%2C+Focused%2C+Well-Named+Tests
2012-09-23T03:45:55+00:00
@@ -0,0 +1,2 @@
+それぞれのテストを小さく、焦点がしぼれたものにしておくのがもっとも簡単な方法である。
+小さいテストの名前はなにがうまくいっていないのかを説明してくれる。]]> -
member/Chapter23/Design to Fail
http://devtesting.jp/goos/?member%2FChapter23%2FDesign+to+Fail
2012-09-23T03:44:47+00:00
@@ -0,0 +1,15 @@
+テストの目的は通すことではなく、失敗することにある。
+プロダクションコードはテストを通ってほしいが、同時にテストコードには間違いを検出してほしい。
+失敗するテストは仕事をこなせているテストである。予期しなかった関係ない場所で落ちても、今まで知らなかった依存関係があきらかになるから、良いことだ。
+
+テストの失敗の原因が検出できない事態は避けたい。
+それはテストが我々の要望を的確に反映できていないことを示している。
+
+!! Stay Close to Home
+
+できるだけこまめにリポジトリと同期するようにしよう。できれば数分に一回。
+テストが予期せずおちたら、すぐに変更をとりけして戻れるようになる。
+
+ときにはうまくいかないところでごちゃごちゃするよりも、一回もどってクリアな頭でやりなおしたほうがいい。
+
+この章では失敗したときに十分な情報をもたらすテストの書き方を考察する。]]>