ToMmY Makes Love with Codes

■[勉強会][TDD] TDDBC 東京 1.5

感想

• ペアプロ初体験。意外といける(後述)!
• 無線LANが途中から死んでしまった。ネット環境関係の愚痴は毎回書いている気がするので、そろそろ自分で用意しろ。
• 講師id:t-wadaさんの話を聞き、その場でためしに実装してみて、フィードバックをうけたりや疑問点を相談できたりする点がすばらしい。
  • 「そこは難しいよね」でも、難しい課題にどうたちむかうかを知ることができる。
• (今回とは関係ないが) Rails のテストは独自なうえ進化が速いので、どこかで勉強したいなあ。

基調講演 t-wadaさん

• Rails をやってる(商用 Rails プラグイン)
• TDD の啓蒙
• きのこ本 #97prog_ja

Boot Camp にようこそ

集中して訓練して、マスターする場

• ペアプロ体験
• コードレビュー: ひとつの課題を複数人で解くことは普通ない

三本柱 > 三本脚

• バージョン管理: ないと死亡
• テスト
• 自動化: Jenkins, rake, ant, shell などで、単純作業をさける。できるだけ機械にやらせて、人間様は高度なことをやる。

テストの定義

• テストの範囲、おおきさ、粒度についての分類はあいまいで、議論がめちゃくちゃになる。

誰がなんのためにテストするか

• Developer Testing: 今日のメイン
• Customer Testing
• QA Testing: 品質保証。品質を維持するひとが、そのためにやるテスト

Developer Testing

• テストをかきながらコードを書く
• TDD: テストをかいてからコードを書く
• ケント・ベック『テスト駆動開発入門』は読もう (この瞬間に amazon に投げた)

どうやって動作するきれいなコードを得るか

• 完璧なモデルを書いて、それをコードにおとす: 完璧主義。実際むり。
• とりあえず動くものを書いてから、きれいにする。
  • テストかく
  • てきとーに実装する(コピペ実装、アルファベット名前 OK)
  • リファクタ: きれいにできる唯一の力。もっとも重要

TDD のこころ

• ひとつずつ、すこしずつ: 大きい問題を小さい問題に分割するスキル
• ひとりずつしとめる: 一対多を一対一の連続にするスキル
• すばやくまわす: 1,2 分でまわす。このために上記二者が必要

• 自分が最初のユーザ: 自分がつかいにくいコードをさらしたりしない(ドッグフードをたべる)
• 道具にこだわる: editor とか
• 不安をテストに: getter / setter にテストを書く必要はないよね

デプロイにさいして

• 三本柱のすべてが必要(テストでチェック、scmでタグづけ、デプロイは自動化)

なぜ TDD するのか

• 目的ではなく手段
  • 目的は「健康」
    • 健康なコード: ムダがないコード。リファクタリングされたコード
    • 健康なチーム: 毎日 RedBull をのんでいてはいけない

• 自分は一発で完璧なコードを書けるハッカーではない。
• 工学的、生産性の問題ではなく、心理的な問題(コード・プログラミングに自信をもつ)

事例

わかりやすい説明: 「コード実装時間が2割増えて、バグが半分になる」

• 仕様要求が洗練される
• コード時間がふえるのに、開発工数はへったとかんじる = デバッグの心理的負担がおおきい。当て推量
• ここ数年デバッガをつかわずに暮せている: デバッガは挙動をしらべるため(コードリーディングとか)につかう

応用

• 既存のコードをテスト可能にし、テストを書く。 マイケル・C・フェザーズ "レガシーコード改善ガイド(ObjectOrientedSELECTION)"
• すでに利用しているデータベースがある。 スコット W アンブラー "データベース・リファクタリング"
• テストがもろい、おそい: 一部をかえるといっき Fail するようなテスト。リファクタしにくくなる。数がおおい、db access がおおい: Gerard Meszaros "xUnit Test Patterns:RefactoringTestCode" (xUTP)
  • index at XUnitPatterns.com を書籍化したもの。
• goos: モダン TDD のバイブル

まとめ(この先生きのこるために)

• acts_as_professional: プロとしてのたしなみ。テストをかくのはプロとして当然
• 写経

twitter:76867991328931840

TDD はじめました @ShiroKappa

TDDを組織でがんばる。

会社がすべきこと

• イノベーション
• 品質
• コストパフォーマンス
• 職場の環境: ひとりではできないことを会社が実現してあげる

TDD はじめました

• id:t-wada さん
  • OSS、コミュニティに還元したい
  • はやく成果だしたい
• 塹壕より TDD
  • 孤立無援、戦場をさける
• 脱却したいもの
  • うごかないソフトウェア
  • 属人的永年保守: あるソフトウェアがひとりの人にしかメンテナンスできない
  • めんどい手動テスト
  • 薄氷をふむおもい(deploy がこわい)
• 獲得したいもの
  • 安心感
  • 攻めの姿勢
  • 価値の共有

これだけ価値があるから、組織で導入しよう

• 自律(自分で考えて能動的にうごく) / 協働(チームで) / 実践

git のつかいかた わたし

Git のいろは

一人反省会

• ローカルで git を使う際の入門用プレゼンとしては、まあよくできていると自負している。
• だが場違い。
• 予想以上の分散バージョン管理システム使用率。
  • やることねえ
  • 事前に雰囲気を把握しておきたかった
  • 全体的に参加者のレベル高すぎ。じつはみなさん TDD とか余裕ですよね!
• ust もされていることだし、あきらめて少人数の人にむけてプレゼンすべきだった。
• てんぱってて時間管理をわすれた。
• スライドが google-chrome じゃないと動かない(かも)。
• つぎはがんばる。

Windows 環境での運用についての指摘

日本のトップ gitter として名高い @bleis さん、ありがとうございます。

以前しらべた範囲では、 GUI なもの(TortoiseGit ほか)はコミットログ、ファイル名ともにダメダメで、msysgit もなにも設定しない状態ではファイル名とコミットログが文字化け、 cygwin はそのへんがなんかしらマシ、みたいな記憶。

環境によっても違うだろうし記憶ちがいもあるので、他にもご指摘おまちしてます。

twitter でながれてたキーワードより

git の GUI フロントエンドってなにがいいのかな。

• Index of /tig

人類ペアプロ計画 @HIROCAST さん

重要なルールを伝授

• どうやって普及していくか : blog に

ペアプロあるある

上手動で導入したものの、がんばってもうまくいかず終了。

解決策としての TDD

How To

• 話す: おたがいのコンテクストを共有する。
• ハイタッチ、拍手する > これいい!
• 集中する: twitter とかやめる。
• 勇気: 自分の実装がただしいかどうかを議論できるから。
  • わからないところはおたがいに聞く
  • 知らないことを認める、ともにすすむ。
• 休憩する: 全力でやるとつかれる。

会社で TDD やってみて、つまづいた。 @remore

MVC でどうしてる?

• 疎結合な model から
  • setup / teardown をうまくつかってやってる
  • 理想: データベーステスト PHPUnit/extensions をつかったり
• controller: ぐちゃってしてるのは設計がわるいから。リファクタリングと並行でやる。
• view: 無理。コードレビューとか。

マイプラクティス

• 日本語関数名いいよ
• いちどバッドノウハウで書いてみて、あとからなおせばいいよ。

生産性の谷

• テストコードを書くと、開発速度がさがったきがする。
• 自分のスキルのせいだと認識する。
• 開発効率がさがった分はじぶんで担保するつもりで。
• テストを書くことがチェック機能をはたしてくれるなど、利点もたくさん。(費用対効果)
• テストのみにこだわらず、柔軟に。

自己満足の砦

• まわりからの無関心。現実とのギャップ
• ずっと Red だとやるきなくなる。
• アウトプット(まわりに愚痴る、勉強会)
• commit するときに assert 数をかいたり
• Red 修正に時間がかかっても、がっかりしない。リズムがくずれても、自分のコードに問題があるのでがんばる。

アジャイルサムライ すごいよ

ペアプロ

課題

基本的な機能をそなえた自動販売機の実装

TDDBC1.5 お題 自動販売機

成果物

https://gist.github.com/1073449

• メタプログラミングうめえwwww的な部分はすべて私の責任です。
• describe '#method' 中心で書いたが、コンテクスト(オブジェクト状態)中心でもよさそう。
  • 自販機は一回こっきりの呼出ではなく、対話的だから。

感想

• ペアプロで合わせなければいけないのは、言語とエディタだけではない!
  • 企業などでは、もともと同じ環境で作業している。
  • とみたペアはキー配列(がうまく日本語にもどらない問題)と日本語入力に問題が生じた
  • 言語だけ合わせて、あとは github とかでシェアして、書くひとによってPCを変えるほうが楽では。
    • やっていたペアがあるみたい。
    • それってペアプロとしていいの?
  • emacs + DDSKK + azik + 数字<>記号スワップ + 無変換がアンスコ なんて世界二人といるわけない。
    • おれかっこいい笑
  • mac + mi みたいなクセのないエディタのほうがコンセンサスになりうるのでは。
• おたがいがおたがいの行動を監視する役目になれて、 TDD や OO の理論を実践できているかチェックしあえるのが利点。
  • 共通の背景で作業していれば、コード規約のチェックとかにもなるはず。
  • (テストできない or するまでもない)ミスを防止できる。
  • 今回は設定があるていどあったが、それでも実装やテストの方法について議論できた。
• 自分たちのコードを他のチームにレビューしてもらう時間、他のチームのコードを見る時間がもっと取れればよかった。

中盤コードレビュー

テストからオブジェクト内部を触るのはあまりよくない

できるだけ public なものをさわるべき。

FAQ

TDDBC in Tokyo - Google Moderator

導入して失敗した経験

導入しようとして拒否された

• めんどい
• 工数ふえる
• する意味がわからない
• 個人でやっていて、じっさいに向上している

テストメソッド名に日本語をみとめるか

• コーディング規則

ひとりで導入してみて

• まわりの人もテストを書いてくれるようになった。

トップダウンでやると

• 消化不良になる。
• 練習する期間や写経やチュートリアルをする必要がある。
• テストの考え方を難しい対象に適用する方法をまなぶ必要がある。

ぜったいに TDD しなくていい場合

• プロトタイプ開発
  • たくさん書いて比較する場合、イニシャルコストのたかい TDD はむかない。
  • 実装時間はやっぱりふえる。
  • コンセプトが実証されたものは、後からテストかく。
  • あとから書かないのはダメ。
• チョイプロ
  • ログの整形など
  • 一度しか使わない、自分しかつかわないもの
• 寿命のみじかいコンテンツ
  • 保守する必要のないコンテンツ
  • TDD は保守するときに真価を発揮するから

TDD に必要な技術

• CI
• 静的コード解析
• Object Oriented
  • Design Pattern
  • Refactoring
  • TDD の一部になってるけどね

非 web 系の UI Test

• windows 限定: window の状態にたいしてテストできる。
• indigo に Jubula というツールがあり、つかえるかも。 (Eclipse Jubula Project)
• UI のレイヤを skinny にして、うしろのロジックになげるべき。
• 見た目のテストはソフトウェアの品質に直結する。人間が時間をつかってやるべきこと。

DB につなげる

• 繋げてテストしたいのなら、繋げるしかない
• 実際に本番につなげる
  • 接続先が固定でいい場合
• 組み込み DB をつかう
  • sqlite とか、アプリケーションにくみこめる DB をつかう。
• メール送信にも同様の問題

どうやって一人で TDD を布教するか

• 一気にやりすぎない
• まずプロトタイプ
• テストがないと不安、という状態にする
• Selenium は受けいい(Selenium web application testing system)
  • だがメンテコスト高いので、徐々に xUnit 併用に移行していく

どんなときにテスト駆動のルールを破るか

• 一番乗りにならないといけないケース
• ワンライナー笑
• 相手がなんだかわからないとき
  • とりあえず、テストの書きかたもわからないので、ごにょごにょしてみる。
  • そのあと、学習テストという形でテストにしてみる。

テストコードのリファクタリング

• 仕様要件がかわると、テストの設定をいじらなければならない場合があるので、しておく。
• 混乱したテストを複数のケースに分割する
• "Clean Code"にも書いてある。

• テストコードを意味のある単位に分割することが重要
• 数年前までは、しないほうがいいといわれていた
  • テストにはテストがないから
  • テストメソッドをみればすぐわかる
• 近年では重複がおおすぎると変更の阻害要因になると問題視される
  • DRY にする
  • いつもやっておくのがベスト
  • テストのカバレッジがかわっていないことを確認
  • mutation testing: product code に変更かけて、きちんと fail することを確認する

懇親会

• かなり濃ゆいメンツであることをやっと理解した。
• かなり大規模なエディタ戦争が勃発していた。
• MacBook は逆ナンまである。
• 中二最強
• ゆとり最強

ツイートする

Permalink | コメント(0) | トラックバック(2) | 00:09