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

Java 勉強会

めも。

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

会場提供のドワンゴ様に感謝。

1. id:t-wadaさんによる講演

  • 第一回のまとめ
    • たのしかったですよ
    • 前回のKPT
      • 撮影が入ってよかった
      • 自由に発言してどんどん訊ける雰囲気が良かった
        • 今回も自重せずに喋って下さい
      • ペアの交代が無かった
        • 今回は１〜２回交代したい
      • かにチャーハン、ラーメンサラダ自重
  • TDDとは？
    • 「テスト駆動開発入門」ケント・ベック
    • TDD
      • テスト書く
      • そのテスト実行させて失敗させる(Red)
      • 目的のコードを書き
      • テストを成功させる(Green)
      • テストが通るままでリファクタリングを行う(Refactor)
      • 繰り返す
    • テストの分類
      • QA Testing
      • Customer Testing
      • Developer Testing
    • Developer Testingとは
    • JavaならJUnit
    • テストのための三本柱／三種の神器
      • バージョン管理
        • バージョン絵巻物
      • テスティング
        • 素早いフィードバック
      • 自動化
        • Make, Ant, Hudsonなど
        • XFD(eXtreme Feedback Device)
          • テストが失敗したとき、通ったときに赤／緑のランプが点灯
      • どれか１つでも欠けているとだめ
    • 動作する、きれいなコードへ
      • 二つの道がある
      • きれい⇔汚い、動作する⇔動かない、から四象限でみる
      • TDDと黄金の回転
        • Red→Green→Refactoring

        • id:t-wadaさんの(会社の)アイコンはそれをイメージしている
    • TDDはテスト技法ではない
      • TDDは品質を保証しない
        • ただし、TDDは品質を向上する
      • TDDは設計技法です
    • TDD、ミクロの視点、マクロの視点
      • 最近はTDDをどうやれば、よりTDDしていて困った、という問題の方が多い
      • プロジェクトが大きくなるとテストが終わるまでの時間が長くなったり
    • 普通のプログラマは、頭の中だけでは管理しきれない
      • だからTDDで設計する、設計し続ける
    • テストは目的ではなく手段である
  • TDDのこころ
    • 「一つずつ、少しずつ」
      • 次の一歩を考えるのが、TDDのスキル
    • 複数を相手にしない。ひとつずつ対処する
      • 宮本武蔵の１対多の戦い方
        • 如何にして１対１にしていくか
    • 「すばやくまわす」
      • スピードもスキル
      • REPL(Read Eval Print Loop)
      • Javaの対話環境：IDE+JUnit
        • System.out.printlnでの対話はだめ？
          • →最初はそれでもいい。それから共有できるようにすれば良い
          • Characterization Test
            • 今、コードがどう動くのか、を確かめるもの
            • テストの無いレガシーコードに手を入れるときなどに
            • Testとして正しいかどうかとは別の話
        • 学習テストとは何ぞや？
          • Characterization Testの前身のような
          • ライブラリなどの動作を調べるための、学習のためのテスト
        • テストのカテゴライゼーションが出来るといいな
          • タギングして実行するテストを区別したりとか
          • 変更したところに関係する部分をテストするようにする、とか研究中らしい
    • 「自分が最初のユーザ」
      • eat your own dog food
    • 「不安をテストにする」
      • どこにどれくらいテストを入れるか、個人のスキル、ケースバイケース
    • 「勇気か 蛮勇か」
    • 「脳を無駄なく」
      • 老人力、ジャグリング
        • 問題をできること、できないことに分けていく
        • 無理してたくさん投げず、少ない数をくるくる回していく
    • 「IDEを使いこなせ」
      • 使いこなしているヒトが動画を上げるべき
      • Eclipseの提案力はすごい
    • 「テストは人の為ならず」
  • TDDはじめの一歩
    • 一人でも始められる
    • 写経
    • YouTube, ニコ動でも探せるよ
  • 本の紹介色々
  • まとめ
    • 三本柱
    • TDDのこころ
    • 黄金の回転


2. id:kompiroさんとid:t-wadaさんによるJUnitMax、ペアプロのデモ

  • JUnitMax
    • 商用テストツール
    • ファイル保存で自動的に
  • テストメソッド名に日本語を使ってもよい
    • それによってテストの内容がよく分かるようになる
    • public void 壱足す弐は参であること() throw Exception {
  • Templateを編集すると自動で行われる操作を変更できる
  • Ctrl+1でとにかく色々できる
  • ペアで書いてない方は良い名前を考えたり調べたりしてみる
  • まずはExpectedな答えを返すだけの仮実装でも良い。とにかく緑に
    • TestCaseのTestをするため
    • Testとして正しく動くかどうかはそこでしか分からない
  • テストに使う引数をどれくらい変化させるか
  • TestのDRYは是か非か
    • 一つのテストを一つのTest中で完結させるか、共通処理をまとめるか
    • やはり言語、環境、テスト内容でケースバイケース？

追記

ペアプロ。隣の席の方と組んでみた(お名前聞き忘れた。大失態orz)
とりあえず自分のPCでEclipseをつかって「PriorityQueue的なものを作ってみよう」、というお題でチャレンジ。微妙にキーバインドを弄っていたので使いにくかったですね。ごめんなさい。


まずは軽く必要になるであろうテストを挙げ(enqueue, dequeue)、とりあえずテストが失敗する(赤くなる)ものを書く。成功する値を返すよう(緑になるよう)実装する。まともに動くようリファクタリングする。
例えばenqueueとdequeueのテストをするにはそれぞれ単独でできるわけではなく、両方を使う必要がある。とりあえず最低限のものから片方ずつ作っていって、ある程度使えるところまできたと思ったら両方使うようなテストも作っていく。
最初はとにかく簡単なQueue操作をできるように、と作ったので中身に入れるのはint変数だけにしたけど、あとから「intの値とpriorityを持つクラス」に拡張する必要がでてくる。一気にテストも実装も書き換えるわけにはいかない。id:t-wadaさんからアドバイスをいただき、まずは今のテストが通る状態を保ったまま機能を拡張し(Objectで出し入れようにする)、そこから徐々に広げていく、ということに。
残念ながらそこで時間切れ。
あとから懇親会で直接訊いたところ、最初にint型のみを対象に作ってしまったのならまずはそれも受け入れるように作り、一通り機能が揃ったところでdeprecateにしていく。とのこと。そういう場合には一度書いたテストを変更するのも仕方ない。


初めてのTDD、初めてのペアプロ。やっぱり他の人と話し合いながら書いたり、他の人が書いていくところを見たりするのは多くの気付きがあって面白い。
そしてTDDで「黄金の回転」を続けていく過程は、やはり自分自身で経験しないと分からない、と思った。話を聞いているだけでなく、成果物を見るだけでなく。テスト書く→実装書く→リファクタリングする、の流れでコードが成長していく様を、ライブで感じなくては。
動画を見る、のも一つの手段かもしれない、とにかく時系列で変わっていく様を感じ取らないといけない。まぁでもひたすら動画見て学ぶよりは、実際にペアプロしながら経験するのが一番だと思う。
また機会を探して色んな人とペアプロして、TDDを実践し、自分の中に叩き込むようにしたい、と思った。


そういえば今回知りたかったことの一つ「GAE/JのようなServlet/JSPのWebアプリでTDD」って具体的にどうやっていくのだろう。考えてみよう。