2011-06-06 TDDXD第2回に参加してきた
今日のはじめて
一言
具体的な問題を与えられると、人とたくさんの議論ができる。これはとても楽しいことだと思う。もちろん損得の関わるビジネスではなかなか難しいのだけど、読書会のような場でペアプロすることで、その貴重な時間が得られた。
きっかけ。
今回の経緯は、TDDXDの一回目が行われたというのを何かで目にしたことがきっかけ。二回目が行われるときは是非参加しようと思った。そんなおり、タイミングよく二回目の予定がtwitterで流れてきたので、さっそく社内の開発メンバに誘いをかける。結局何人かはこなかったので、二人で参加になったのだが・・・。
始まりはペアプロ
読書会は、ｇｄｇｄながらも速やかに行われた。おそらく初めから興味を持って参加している人だけが集まっているからだと思う。机を輪にし、周りに座り、隣の人とペアプロ。所見の方とはじめましてとツイッターIDを教えあい。じゃあ、このMacBookでやりましょうとスタート。
手順は簡単
- 少し読み進める。
- テストコードを書く。
- 実装コードを書く。
- リファクタリングをする。
ちなみに、テストの実行はほぼ毎回やる。すすめるごとにとりあえずテスト。レッドかグリーンか。はたまたコンパイルエラーか。今の状況を逐一確認しながら、写経を続ける。
今回のTDD本では、TODOリストの変化をメインに話が進んでいく。
なぜこのTODOが追加されるか、消されたか。
それを理由にどうコードに手が加えられていくか。
わからないことは逐一確認。（立ち止まりそうなら、あとで皆で議論）
時間はあっというまに過ぎる
初めての体験ということもあったのか、時間があっという間に過ぎた。とても充実した時間を堪能。
最後の議論の時間に、これが途中の議論の時間かなーと思っていたぐらいだ。
懇親会
参加したかったのだけど...
体験を経験に
積み上げていきたいと思う。経験値を貯めてTDD力をつけようじゃないか。
- 写経を続ける。
- 会社でもさそってやってみる。
失敗してもいいので挑戦してみよう。あとからグリーンにすればいい。
2010-01-25
2009-07-26
テストしやすくするためにー
ってあたりかなぁ。
こいつとこいつの距離を・・・とかそういうために設計しても、これいらねえんじゃね？とか理解されないことが多いけど、そういう間を持たせないと・・・ねぇ？
ああ、そういうところはLL系の言語が融通が利くんだな・・・Javaとかはどんどん面倒になっていく・・・
Javaは面倒になるから簡単にかくと簡単に扱えなくなる・・・がちがちにかくといいけど、それはそれでってなるのかなぁ。
テストしやすいというのはどういうことか。
っていうのをちょっと考えてます。
WebのプログラムっていうのはMVCに分かれてるとか、特にモデル部分っていうのはDBにアクセスする部分とビジネスロジックとが分離してるといいよ。それらが別々にテストできるといいとか。何かができてないときは、そこをモックで生めてテストするとか。
たぶん、そんな感じなんだと思います。
でも世の中はそんなにうまくなくて、ぐちゃぐちゃなのが大半で。それをどううまくテストするかっていうことに頭を悩ませるのがお仕事なんだろうなぁ。
いっちゃん簡単なテスト。
ブラウザで開いて、表示されるかどうか見る。
この辺が一番初め。
いろんなパラメータで試す。
んで、それだとアプリ単位でのテストだから、さらに中身を切り分けて・・・っていう段階なのかな？
そもそもこれって結合レベルのテストだよね。処理単体でのテストを書く方がバグが防げるとか、バグが起きたときに範囲を絞れるとかそういう利点があるんだよね、たぶん。
もうちょっと掘り下げて考えよう
メソッド単体でユニットテストを書く。
んで、実行するのに必要なことは？それが単体で実行できるかどうかっていうこと。
引数で渡すオブジェクトは用意できるかどうか？処理が大きすぎないかどうか？
DBの状態はどうなっているか？
DBの状態に依存しないテスト、パラメータに依存しないテスト。この辺はDBやパラメータ単体でのテストが必要になるだろうし。
そういうきりわけが必要。
もちろんメソッド一つでは文脈的に意味が無い場合も多いし、クラスが組み合わさって動作する場合にはその単位でテストするのに意味があるだろうし。
ただ、それらが最小の範囲に収まるようにうまくテストしないといけませんよね。
書きすぎるテスト？
そこまでする必要があるのかが分からないテストもあるかもしれない。
必要なのは、失敗しそうなものを探すことかもしれない。
きわどいこと。
仕様を確認したいなってところ。
境界線ぎりぎりのところだったり。
一般的じゃない。そもそもこうしてくれっていう願い以外のところ。
まずは処理の噛み砕きガ必要。
あとは、依存性を少なくすること。
オブジェクト指向ってやつだ。
そのクラスの状態はそいつが責任もたないといけない・・・とか。
メソッドの引数がやたらおおかったり複雑化してもいけない・・・
あー、副作用があるとテストできないか・・・それが大きいな。