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

日々常々

ふつうのプログラマがあたりまえにしたいこと。

TDDBC 福岡 1日目 午前のメモ

イベント

TDDBC 福岡に参加しています
http://kokucheese.com/event/index/7040/

1日目午前は和田さん( id:t-wada @ )の講演でした。

テストの混乱

皆が重要だという「テスト」だけど、それが指すものは多種多様。その違いを解決しないと、TDDを語ることがまず不可能になる。分類する方法はいくらかあるけれど、テストは何のためにやるかで分けると、以下の三つになる。どのテストももちろん重要。

  • DeveloperTesting 開発者のため
  • CustomerTesting 顧客のため
  • QATesting 品質保証のため

TDDは開発者のためのテスト。テストは現代ソフトウェア開発の三本柱*1の一つ。三本柱は三脚椅子の脚をイメージする。1本でもかけると椅子として成立しない。

DeveloperTesting

プログラマの、プログラマによる、プログラマのためのテスト。

旧来よりテスト方法は色々あったが、xUnitはテスト方法の共有化を促進した。テスト方法が共有化されると、テストの実行から属人性*2を排除できる。テスト方法が人に依存しなくなると、テストコードを書いた人以外に引き継げる様になる。誰でも実行できるものは、コンピュータにも実行できる。コンピュータによる自"働"化が実現できる。

よいテストとは

  • A-TRIP
    • Automated
    • Through
    • Repeatable
    • Independent
    • Professional
  • F.I.R.S.T.
    • Fast
    • Independent
    • Repeatable
    • Self-Validating
    • Timely

テストコードもDRYに書く。きちんと。

動作する、きれいなコード

動作するきれいなコードは最終目標で、到達するのに2つの道がある。出発点は動作しないコード。ひとつは動作しないきれいな設計を作り、それから動作するきれいなコードを作る。よい設計が、よいコードを生ませる。もうひとつが動作するコードをまず作り、そこからきれいにする。よいテストに、よいコードを育てさせる。TDDは後者。

TDDはRed,Green,Refactoringのサイクル。きれいな方向への力はRefactoringしかない。RedとGreenだけでTDDを語ると、単なる動作するコードしかできない。
Redはコードを汚く、動作しなくさせるベクトル。Greenは動作させるだけのベクトル。Refactoringはきれいにするだけのベクトル。二つ以上のことを同時にするとバグが混入しやすいため、ひとつずつやる。

TDD三原則

  • 失敗するテストを書く前に製品コードを書いてはならない
  • 適切に失敗するテストができるまでは、次のテストを書いてはならない
  • 失敗しているテストが通るまで次を書いてはならない

テストを追加できるのは全てのテストが通っている時だけで、追加するテストは常に失敗するもの。一歩一歩進まなければならない。

TDDのこころ

TDD三原則はトテモ厳格。それに対する和田さんのアレンジ。

  • 一つずつ、少しずつ
    • 高い塀を乗り越えるには、適切な高さの階段が必要。
    • 適切な高さの階段を作るのがTDDのスキル。
  • ひとりずつ仕留める
    • 大きな問題を一気に相手にしない。
    • 適切な粒度のテストを一つずつ相手にする。
    • 一度にやっちゃうとパンクしてしまう。
  • すばやくまわす
    • TDDはサイクルなので、回転が遅いのでは意味が無い。
    • 可能な限り小さく早く回す。
    • テストは常にすばやく実行できなけれなばらない。
    • そのフィードバックを即座に受ける。
  • 自分が最初のユーザ
    • TDDでは間違いなく自分が最初に自分のコードを動かす。
    • 使いやすいか使いにくいかすぐにわかる。
    • フィードバックを受けて舵取りする。
  • 道具にこだわる
    • 常に道具を磨き続ける。
    • サイクルを最速でまわせる状態を保つ。
  • 不安をテストにする
    • TDDでテストするのは不安なところ。
    • これは開発者に依存する。
    • 不安の無いところはテストに書く必要が無い。
  • 祈るのではダメ
    • TDDは運任せの状態(Edit&Pray)を作らない。
    • 緊急時もテストがあればフィードバックが即あるので慌てなくていい。
    • 命綱をこつこつ編むのがTDD

私たちは完璧なプログラマではない。最初から書けるほど対象は単純じゃない。近づかないと見えないものは多いので、すばやく対象に近づき、フィードバックを得て方向修正する必要がある。大事なのはフィードバックを得ることで、TDDはその入力を最大限増やすもの。
TDDの工学的なメリットは色々あるが、最大の理由は心理的なもの。

  • 即座にフィードバックを得るため
  • 書いたコードに自信を持つため
  • これから書くコードに自信を持つため

TDDの真の目的

健康

コードの健康のため。変化に対応出来るのは健康体のコード。コードには必ず変更が入る。健康体のコードには贅肉が無いので、変更に対応出来る。
チームの健康のため。変化に対応出来るのは健康体のチーム。精神的、身体的な健康状態を保つ。変な状態を作らない。

プログラマの不安の克服、健康の維持。

TDDの売り文句

「TDDをやると実装時間が2割増えてバグが半分になります」
「TDDをやると実装時間は増えますが開発工数は減ります」

本を読もう、写経しよう

技術書の写経 でググれ。
ググった → http://www.google.co.jp/search?sourceid=chrome&ie=UTF-8&q=%E6%8A%80%E8%A1%93%E6%9B%B8%E3%81%AE%E5%86%99%E7%B5%8C

TDDと黄金の回転を覚える

  • TDDはスキルである。
  • 才能ではなく、習得可能。
  • 量は質に転化する。
  • 写経が有効。
  • 大事なのはやること。
  • やらないとできるようにはならない。
  • やればできるようになる。

*1:バージョン管理、テスティング、自動化

*2:テストを書いたAさんしかテストできない等