TDDBC参加メモ.md

• TDDの目的は健康

• 爆弾処理のようなリリース

• complexとcomplicated

  • 複雑なものとややこしいもの
  • TDDはややこしいものに対処する

• デベロッパーテスト

• TDDはチームを支援するためのもの

• バグを見つけるためのものではない

• ひとりずつ相手にする

• 自分が最初のユーザー

• 不安をテストに

• 祈るのではダメ

• 要素分解

• ひとつずつ

• テストを書くときは下から書く

• テストがちゃんとしたテストかどうかを最初に確認する

• 仮実装 Fake It

• コメントはテストできない。実装と乖離していく

• 三角測量 trianglation

• 不安がなくて、自信があるならテストと実装を同時に

• 自分の歩幅に合わせてコードを変える

• 明白な実装

• Obvious Implementation

• もう慣れているならテストのケースは減る

• 品質保証のテストではない

• TDDはデベロッパーテストである

• 最近のテストコードはテストクラスをネストできる

• @RunWith(Enclosed.class)

• インナークラスでグルーピング

• 仕様とケースの見える化

• TODOリストを作る

• 例外のテスト

• @expectedを使うといいよ

• スコープが広い変数名ほど説明的に命名する

• 引数は忘れがち

• テストのグループ化は状況と機能の二通り

• 状況を作り出すのが得意なものが多い（テスティングフレームワークは）

• setupとかがあるから

• テスト駆動開発の効果

• 安井さんのブログ

• 開発２割増えて、欠陥が７割減る

• データベースリファクタリング

• xUnit Test Patterns

• ソフトウェアテスト技法ドリル

• 実践テスト駆動開発入門

• テスト駆動JavaScript

• 組織パターン

• TDDはスキル

• ペアプロ

• 全部は難しい

• 障害対応はペアプロ

• 新しいメンバーの最初の一週間

• 情報伝達力が強み、効果的

• TODOリストを作る

• MECEの考え方は変わってきた

• 自動化によりテストのコストが下がってきた

• 人力の場合は神の一手を目指しがち

• デバッグのコストも低い

• バグ解析も用意