02 『JUnit実践入門』写経・実践会 in 横浜 #3 #junitbook

strict mock でテストがどばーとコケたりするのは、インターフェースじゃなくて実装のテストになってしまっている。　#junitbook

2013-02-02 16:56:49

テスト対象以外を全部mockにするのがmockist #junitbook

2013-02-02 16:59:11

sut以外は全員モック！： mockist #junitbook

2013-02-02 16:59:36

mockをあまり使わないのがclassist #junitbook

2013-02-02 17:00:00

ムンク @skowata

モッキストとクラシシスト、かぁ #junitbook

2013-02-02 17:00:23

classist と mockist の宗教論争（スペルあってるかしら） #junitbook

2013-02-02 17:00:41

#junitbook 和田さんが言及しているのはこの辺かな？ / Classicist vs. Mockist Test-Driven Development | Ian Cooper http://t.co/3f6uqWmr

2013-02-02 17:01:08

モックの利用を促進させると、オブジェクト達がどう会話すべきか、に目が向きやすい #junitbook

2013-02-02 17:01:17

とーます @grimrose

周り全部偽物にしておくのは、全体を見えなくして単体を際立たせてユニットテストをするため。#junitbook

2013-02-02 17:03:12

例外状態を作りやすいのがテストダブルの利点 #junitbook

2013-02-02 17:04:36

とーます @grimrose

外部エラーをMockで置き換えるというのは、始めて知った。 #junitbook

2013-02-02 17:04:40

ネットワークが失敗したところのテストを作れる、例外条件を作りやすいのがテストダブルのメリット　#junitbook

2013-02-02 17:04:47

ムンク @skowata

例外条件を作りやすいのがモックの良いところ #junitbook

2013-02-02 17:04:52

スタブの動作は本物と同じなのか？ <- 悩ましい点 #junitbook

2013-02-02 17:06:46

npub1hqmrddql4em63chfs02x8cx86alrdss9m4kxevpjzwwgc @ryu22e

本物の振る舞いが変わったけどモックのメンテナンスをやっていなくてバグに気づかないというケースはありえる。#junitbook

2013-02-02 17:06:47

テストが全部通ってるのにバグった、なぜ？　→　モック使ってたんだけど、本物の方の動きが変わってた。おそろしや。だから他のテストも併用しないといけないのか。　#junitbook

2013-02-02 17:06:56

npub1hqmrddql4em63chfs02x8cx86alrdss9m4kxevpjzwwgc @ryu22e

mokito=モック伊藤説が和田さんに完全に否定された #junitbook

2013-02-02 17:07:55

mockitoは「モック伊藤」じゃないことだけは確かｗ #junitbook

2013-02-02 17:08:13

#junitbook Mockitoの発音について、@t_wada さん『モック伊藤でない事は確かです』

2013-02-02 17:08:59

とーます @grimrose

#junitbook How to pronounce 'mockito' - Google グループ https://t.co/HHI32vXj

2013-02-02 17:09:35

#junitbook 引き続き『11.3 Mockitoによるモックオブジェクト』の黙読へ。

2013-02-02 17:11:18

Mockito.verify()を上手く使う事で、SUTが依存オブジェクトをどう利用するか、を規定する事が出来る訳ですね。neverとかatLeast, atMost, onlyまである。でも、やりすぎると「実装のテスト」になってしまう危険がある。 #junitbook

2013-02-02 17:13:06

Eiji Ito @aeg

テスト駆動開発界では、Mockist とClassist の果てしない戦いが繰り広げられているのかっ。 #junitbook

2013-02-02 17:13:27