読者です 読者をやめる 読者になる 読者になる

FLOSS桜山 第12回勉強会へ行ってきた

FLOSSS report

そんなわけで今月も行ってきたのでレポートを。ヤマモトさんのプレゼンのまとめはちゃんと見直してないので、日本語がおかしいところあるかも。

テスト駆動開発のエッセンス(名古屋アジャイル勉強会 ヤマモトさん)

デブサミ2008で平鍋さんが言っていたリーン開発の本を読んで、「テストは在庫、在庫は無駄、だから後回しにしない」ってのが頭に残ってるので、非常に興味深い内容でした。

テスト駆動開発とは?
  • テスト駆動のコンセプト
    • 開発を予測可能にする
    • コードからノウハウ
    • ソフトウェアユーザの生活を向上
    • チームメンバー同士の信頼を築く
    • 開発を心地よく
自動テスト
  • 何の役に立つの?
    • デグレ検出
    • ドキュメント
    • debug tool
    • 進捗の指標
  • 自動テストはタダではない
    • 作成コスト
    • メンテナンスコスト
  • 自動テストセットの価値を高める
    • 早く使い始める
    • 繰り返し利用する
      • コンパイルする度に・・
      • 継続的にビルド(ビルドサーバで、定期BATでビルド)
      • インクリメンタル・イテレーティブ開発
  • 作成コストを下げる
    • テストを書きやすい設計
      • 疎結合
      • テストを書きながらコードを書く
    • メンテナンス製を上げる
      • 依存性を減らす
      • 単体テストを自動化
      • ひとつのテストはひとつのことしかしない
      • モックオブジェクト
ユニットテスト
  • ユニットテストの書き方
    • 厳格なテストファーストでなくていいんじゃね?
    • クライアントコード例を書くつもりで
  • 全工程テストセット
    • 既存コードの振る舞い(In/Out/状態の変化)をデバッガ、ユニットテストとして記述
    • テストセットができればこちらのもの、デグレ検出・バグ検出
テスト駆動開発手順のねらい
  • テストを少し、コードを少し
    • 作りすぎを防ぐ
    • 構造化
    • 安心
  • レッドグリーンリファクタリング
    • リズムを与える
  • 手順はオプションだが、理にかなっている
テストフレームワーク
  • シンプルなもので十分
    • MinUnitはたった3行
自動テストセットが満たすべき性質
  • 簡単実行
  • 自己検証
  • 繰り返し可能
    • 日付とかが変わってもちゃんと繰り返しつかえるやつ
  • 独立性
    • DBとか依存しちゃってるのをなくす
いまどきのアプリケーションフレームワークに求められるもの
TDDのテストってテストではない?
  • デバッグではない
    • 要はサンプルコードを書いている
    • example or specと呼ぶ 振る舞い駆動開発
  • テスト駆動開発の品質モデル
    • 早く直せば早く上がる
    • TDD的な意味でのテストしていないものがない
    • デバッグ不要
    • 品質保証的なテストが不要だとは言ってない
テスト駆動が合わない開発
  • 探索的な開発とは合わない
    • 割り切って後から書く
    • 後からプログラムをテスト駆動で書き直す
  • 制約を課することで洞察を得るのが手法としての目的

Squirrel Mailと予約プラグイン(NPUG 沢田さん)

Squirrel Mail(GPLWebメールソフト)の簡単な紹介と、沢田さん作の予約プラグインの紹介とデモでした。

勉強会/第12回勉強会 - PukiWiki でプレゼン資料が公開されてますが、実際のプレゼンではかなり省略されてました。

予約プラグイン

Javaで自作 O/R Mapper(富永さん)

タイトルとしては富永さんが作っているO/R Mapper YADao(Yet Another DAO、やだお)の話がメインのはず…でしたが、時間の関係で本題は持ち越しに。
タイプセーフenumとか、アノテーションとかリフレクションとか、Java 1.5 から実装された機能の説明がほとんどでした。

その後の懇親会や別の機会でYADaoのソースを見せていただいたり、設計思想の話なんかをしていただきました。

  • アノテーションダイナミックプロキシを駆使
    • そもそもなんでダイナミックプロキシに?ソースジェネレート型の方がSQLのカスタマイズ性も実行速度も…
      • Android 対策を考えていて、ソースジェネレートしちゃうと組み込み向けにはアプリのサイズが大きくなりすぎてしまう
  • まだ本当に基本的な事しかできないけど、ソースコードは2kステップぐらい
  • クライアントプログラムは本当にアノテーション・インタフェースの定義ぐらいでOK
  • 今後、外部SQL(SELECT文)は書けるようにしないの?業務系システムなんかに近寄るとキモいSQL書けないと…
    • 考えてないことはないけど、優先度は低い
    • Android で動かす組み込みDBでそんなキモイSQL書くことがないかも