第二回チキチキ 日本ペアプログラミングの会java-ja支部会（仮）

java-ja 勉強会

http://java-ja.yoshiori.org/index.php?%E7%AC%AC%E5%8D%81%E4%BA%94%E5%9B%9E
30分遅刻した

テスト
  • 開発者
  • 顧客
  • 品質保証

それぞれの立場でのテストがある

現在のソフトウェア開発三本柱
  • バージョン管理
    • branchをどこまでmergeしたかとかの管理が大変だった
    • モダンなSCM(Mercurial,Git)ではその辺憶えててくれてるから楽になったよねー。
  • テスティング
  • 自動化

3本足のイスの足みたいなものなので一つ破綻すると全部破綻する

動作する・きれいの2軸

red→green,refactoringのフィードバックサイクルは色んなスケールで回す。

TDDと品質
  • TDDは品質を保証しない
  • TDDは品質を向上させる

TDDは設計技法です

TDD ミクロの視点／マクロの視点
  • テストケースが増えていくと全部流したときの時間がどんどん増えていく
    • スローテスト
    • 一週1,2日という例もあり
    • どうやって解決していくか？

→テストのカテゴライズをし、カテゴリ別のテストの実行計画をする

  • DBに接続してるとかネットワークに接続してるとかでタギングする
  • とりあえずDB以外のテストを全実行→オールグリーン→DBに接続するテストを実行
  • 実装コードとテストコードが一対一でなくなってくる／きている

TDDのこころ

一つずつ少しずつ
  • 五輪の書に一対多の喧嘩の仕方として「複数を相手にせず、一人ずつ対処する。」というのがある。
  • MercurialQueueの活用とかこれに役立ってる気がすると思った。
  • REPL(Read Eval Print Loop)→対話環境大事
  • System.out.printlnはおkか？
    • 最初はOK
    • テストコードは資産になる
    • もしSystem.out.printlnで出している内容が有用ならassertに取り込むべき
  • キャラクタライゼーションテスト
    • テストコードがないコードがどう動くのか把握するためのテスト
    • とりあえずasserEqualsで空文字列と比較する等して、red出して何が出てるのか把握して、assertに写し取る

テストがある範囲を広げていく

不安をテストに

アクセサとかは不安ない→テスト要らないよね