TDDXD第2回に参加してきた

今日のはじめて

  • ペアプロしたよ！
  • TDDをしながら、それについて話す！
  • 読書会に参加した！
  • ピザに割り箸を使う。

一言

具体的な問題を与えられると、人とたくさんの議論ができる。これはとても楽しいことだと思う。もちろん損得の関わるビジネスではなかなか難しいのだけど、読書会のような場でペアプロすることで、その貴重な時間が得られた。

きっかけ。

今回の経緯は、TDDXDの一回目が行われたというのを何かで目にしたことがきっかけ。二回目が行われるときは是非参加しようと思った。そんなおり、タイミングよく二回目の予定がtwitterで流れてきたので、さっそく社内の開発メンバに誘いをかける。結局何人かはこなかったので、二人で参加になったのだが・・・。

始まりはペアプロ

読書会は、ｇｄｇｄながらも速やかに行われた。おそらく初めから興味を持って参加している人だけが集まっているからだと思う。机を輪にし、周りに座り、隣の人とペアプロ。所見の方とはじめましてとツイッターIDを教えあい。じゃあ、このMacBookでやりましょうとスタート。

手順は簡単

  • 少し読み進める。
  • テストコードを書く。
  • 実装コードを書く。
  • リファクタリングをする。

ちなみに、テストの実行はほぼ毎回やる。すすめるごとにとりあえずテスト。レッドかグリーンか。はたまたコンパイルエラーか。今の状況を逐一確認しながら、写経を続ける。
今回のTDD本では、TODOリストの変化をメインに話が進んでいく。
なぜこのTODOが追加されるか、消されたか。
それを理由にどうコードに手が加えられていくか。
わからないことは逐一確認。（立ち止まりそうなら、あとで皆で議論）

時間はあっというまに過ぎる

初めての体験ということもあったのか、時間があっという間に過ぎた。とても充実した時間を堪能。
最後の議論の時間に、これが途中の議論の時間かなーと思っていたぐらいだ。

懇親会

参加したかったのだけど...

体験を経験に

積み上げていきたいと思う。経験値を貯めてTDD力をつけようじゃないか。

  • 写経を続ける。
  • 会社でもさそってやってみる。

失敗してもいいので挑戦してみよう。あとからグリーンにすればいい。

テストしやすくするためにー

  • 副作用を無くそう
  • テストしたいやつごとに分離しよう
  • 協調動作をうまくさせるためにインタフェースを設計しよう

ってあたりかなぁ。
こいつとこいつの距離を・・・とかそういうために設計しても、これいらねえんじゃね？とか理解されないことが多いけど、そういう間を持たせないと・・・ねぇ？
ああ、そういうところはLL系の言語が融通が利くんだな・・・Javaとかはどんどん面倒になっていく・・・
Javaは面倒になるから簡単にかくと簡単に扱えなくなる・・・がちがちにかくといいけど、それはそれでってなるのかなぁ。

テストしやすいというのはどういうことか。

っていうのをちょっと考えてます。
WebのプログラムっていうのはMVCに分かれてるとか、特にモデル部分っていうのはDBにアクセスする部分とビジネスロジックとが分離してるといいよ。それらが別々にテストできるといいとか。何かができてないときは、そこをモックで生めてテストするとか。
たぶん、そんな感じなんだと思います。


でも世の中はそんなにうまくなくて、ぐちゃぐちゃなのが大半で。それをどううまくテストするかっていうことに頭を悩ませるのがお仕事なんだろうなぁ。


いっちゃん簡単なテスト。
ブラウザで開いて、表示されるかどうか見る。
この辺が一番初め。
いろんなパラメータで試す。
んで、それだとアプリ単位でのテストだから、さらに中身を切り分けて・・・っていう段階なのかな？
そもそもこれって結合レベルのテストだよね。処理単体でのテストを書く方がバグが防げるとか、バグが起きたときに範囲を絞れるとかそういう利点があるんだよね、たぶん。


もうちょっと掘り下げて考えよう
メソッド単体でユニットテストを書く。
んで、実行するのに必要なことは？それが単体で実行できるかどうかっていうこと。
引数で渡すオブジェクトは用意できるかどうか？処理が大きすぎないかどうか？
DBの状態はどうなっているか？
DBの状態に依存しないテスト、パラメータに依存しないテスト。この辺はDBやパラメータ単体でのテストが必要になるだろうし。
そういうきりわけが必要。
もちろんメソッド一つでは文脈的に意味が無い場合も多いし、クラスが組み合わさって動作する場合にはその単位でテストするのに意味があるだろうし。
ただ、それらが最小の範囲に収まるようにうまくテストしないといけませんよね。

書きすぎるテスト？
そこまでする必要があるのかが分からないテストもあるかもしれない。
必要なのは、失敗しそうなものを探すことかもしれない。
きわどいこと。
仕様を確認したいなってところ。
境界線ぎりぎりのところだったり。
一般的じゃない。そもそもこうしてくれっていう願い以外のところ。

まずは処理の噛み砕きガ必要。

あとは、依存性を少なくすること。
オブジェクト指向ってやつだ。
そのクラスの状態はそいつが責任もたないといけない・・・とか。
メソッドの引数がやたらおおかったり複雑化してもいけない・・・


あー、副作用があるとテストできないか・・・それが大きいな。

メモ

jdbcでは、ある時点でたった 1 つのスレッドだけが Connection オブジェクトを使用できる
ゆえに、SQLを送信してからResultSetで結果を受け取るまで他のスレッドがブロックされる。
そのため、Connectionが使用中の場合は別のConnectionを使うといった管理が必要になる。これが接続プール。

多くの JDBC ドライバでは、ある時点でたった 1 つのスレッドだけが Connection オブジェクトを使用できるという問題があります。この問題がなければ、あるスレッドが結果を受け取っている時に別のスレッドが問い合わせを送ることができます。この問題は深刻なものです。 PostgreSQL JDBC ドライバはスレッドセーフです。したがって、アプリケーションで複数のスレッドを使用する場合、同時にデータベースを使用するスレッドがないことを確実にするための複雑なアルゴリズムを考える必要がありません。 あるスレッドが別のスレッドが使用している時に接続を使用しようとすると、他のスレッドの操作が完了するまでその操作は待たされます。通常の SQL 文の場合、操作とは文を送信し、何らかの ResultSet を（完全に）受け取ることです。ファーストパス呼び出し（例えば、ラージオブジェクトからブロックを読むこと）の場合、それはブロックを送信する、または、受け取る瞬間です。 これはアプリケーションやアプレットでは優れていますが、サーブレットの場合は性能に関する問題を発生させます。問い合わせを実行する複数のスレッドがある場合、1 つを除く各スレッドは待機してしまいます。これを解消するために、接続プールを作成することをお勧めします。スレッドがデータベースを使用する必要が発生した時に、スレッドは Connection の入手を管理クラスに依頼します。管理クラスは空いている接続をそのスレッドに渡し、その接続に使用中と印を付けます。空き接続がなければ、接続を開きます。スレッドが処理を終えた段階で、管理クラスに返却します。管理クラスはその接続を閉じることも、また、プールに追加することもできます。また、管理クラスは接続が現在も有効かどうか点検し、もし無効であればそれをプールから削除します。接続プールの欠点は、各Connection 用に新しくセッションが作成されることに伴い、サーバへの負荷が増加することです。これはアプリケーションの仕様によります。

マルチスレッドあるいはサーブレット環境におけるドライバの使用