2014年2月12日水曜日

「TDD LOVE!」(DevLOVE#157)に参加してきました。

 「Growing Learning Feedback Loop, Guided by TDD & Patterns」家永英治氏

TDDの範囲はいろいろあるけど、今日の話は、Acceptance TestingとUnit Testingの2重ループがメイン。
TDDでは、素早く、小さく失敗し、学習しながら前に進むメカニズムが重要。
オートメーションは、学習フィードバックループの回転を加速させる。

TDDのエントリーポイント

  • 1-2人で、対象を絞って実施
  • PO-開発者の受け入れテストから始める
  • チームでScrumに取り組み、デモを始める

学習ループのコアとなる3つの問い

  • Why:ユーザーがほしい？
  • What:期待する振る舞いは何？
  • How:どうすると読みやすい？
この問いに答えるのは人。

初手で行われているコツ

  • テスティングフレームワークの準備
  • まねて学ぶ
  • Red-Green-Refactorのリズム
  • 素振り（写経）
  • ちょと実装-テスト
  • TDDBCに参加する
  • 1人でひっそり
  • 気の合う同僚
  • 界王拳（自発的残業）
  • 個人のタスクボード
  • タイムボックストライアル
  • 適切な時期
TDDBC、素振り（写経）で準備は王道！
「リーダブルコード」も読んでみよう。
TDDを学びあう同僚を見つけよう。

書籍「リーン開発の現場」からのヒント

  • 新機能は普通にTDD。
  • 重要なものからリストアップ。
  • End to Endよりにテストを補強。

その他のヒント


  • 書籍「FEARLESS CHANGE」から
  • 書籍「xUnit Test Pattern」から

「テスト自動化のアプローチ拡張トレンド 〜Excel項目定義手動テストから自動テストへ〜」福井修氏




るびま　に詳しく書いています。
今日はポイントだけ。

DSL（ドメイン特化言語）

  • Chef
  • Fluentd
  • RSpec
  • Gherkin
  • Capybara
今日は、GherkinとCapybara中心に。

結論を先に

  • Rubyの進んだテストツールを使うと自動テストもおいしくええとこどりできる
  • エンドツーエンド（e2e）は、Gherkin+Capybara+Turnipが有利
  • 外部テスト管理もExcelからWebDBに

視点

  • 書籍「継続的デリバリー」のテスト自動化ピラミッド
  • テストのWモデル
  • IPA「高信頼化ソフトウェアのための開発手法ガイドブック」
  • テストの種類（単体、結合、システム、受け入れ、回帰）
  • 内部テストと外部テスト（e2e）
  • DevOpsでDevはカジュアルにテスト、Optの前にフォーマルにテスト

Unitテスト自動化→e2eテスト自動化

  • Gherkinでベタからメタに
  • CucumberとTurnip

gherkin書式

  • TDD/BDD：プログラマー視点
  • e2e：ユーザー視点
どちらも必要。この境界を書けるのがgherkin書式。
gherkin書式の導入でプログラマ以外がテストを書ける。
  1. 機能feature
  2. シナリオ
  3. ステップ
.featureファイルとxx_step.rbファイルがあれば自動化できる。
step.rbファイルを記述するには、Capybara, Rspecの理解が必要。

テストコンテンツの管理

ExcelからWebDBへ。
Rtestdeck：Webから操作できるGUIツール化。

質問＆相談

  • TDDを依頼するとすごい見積もりに。。。どうすれば？
    ->1週間とか試してすり合わせてから全体を見積もるとよい。
    ->お試しで小さくやってみるところからはじめるとよい。
  • Turnipを使って、DBを使うプログラムのテストはどうするのがよい？
    ->DBの設定は内部テスト。Turnipは外部テストなので、レイヤーが違う。
  • POがgherkin書式で書いてくれない。エンジニアがやるならメリットないのでは？
    ->作った人じゃない第3者が書くことが重要。
    ->ボトムアップかトップダウンかが違う。
    ->エンジニアが書いて、レビューしてもらうパターンもある。
    ->ビジネスサイドとエンジニアがペアでやるのもよい。
  • リファクタリングをどこまでやったらいいか基準は持ってる？
    ->同僚に求められる暗黙の基準、期待はクリアする
    ->完璧なリファクタリングは無理。納期などの制約に応じてやるしかない。
    ->理想へのシナリオを用意して、空いた時間にやったこともあった。
  • 同僚がクリーンって言ってくれるまでやってたら、お客様がそこまで要らないと言ったら？
    ->ホントはダメだけど、仕方ないよねというのはある。
    ->後々、お客様にも痛みがあるので、考えながらやるしかない。
    ->制約の中でやるので、あきらめることも必要。
  • 年度が変わったときなど、データをうまく扱うにはどうしたら？
    ->前提データをどれだけ簡潔にメンテできるようにするかが重要。
    ->時間をコントロールする道具も必要。
    ->テストを維持するにはコストが必要。コードを変えるならテストもメンテが必要。
  • テストの文化を広めるときに具体的にどうすれば？
    ->困っていることを話すことから。
    ->TDDBCに2,3人でいってみるのがおすすめ。
  • TDDを社内全体に広めるときにはどうすれば？
    ->そこまで狙わなくても。。。TDDBCに参加しましたとか少しずつ。
    ->「FEARLESS CHANGE」にいろいろあるけど、まずは自分のまわりから。
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)