-
- 高橋邦彦さん
- ディノ(飴の会社)
- 作戦失敗
- 飴はことあるごとに配ります
-
- テストの分類
- １ デベロッパーテスティング
- 2 カスタマーテスティング
- ３ QAテスティング
- 専門テスターがいるのは幸せ
- TDD(Test Driven Development)
- テストはほかの誰かがやるイメージ
- そもそも「きちんと動いているとはどういうこと?」
- このように動作すべき、というのを表現する
- EXELとか(×100)
- コードで書いたらいいんじゃない?
- TDDのステップ
- わざと失敗させるところからはじめる(RED)→ひとまず動かす(GREEN)→リファクタ
- デモ
- Doctest→コードに直接書く
- 何も書いていない→エラーになる
- とりあえずtrueを返す→グリーンになる
- (テスト駆動は最小のことしかしない)
- とりあえずにis_numericと文字列で
-
- テストコードが長くなりすぎる
- 役割を詰め込みすぎ→分割すべき
- テスト駆動開発はいい本だよー
- 「動作するきれいなコードがTDDの目標である」(Clean Code Works)
- 終了から現実へ、現実から理想へ
- テストをしないときちんと動いているといえないから
- テストは今、いつも 自分が作るものすべて。できる限り細かい単位で
- 質問コーナー。
1 プライベートメソッドをどうテストするか?
JAVAだとリフレクションを使う。アクセス修飾子を何も書かないとパッケージ内でアクセスできる。PHPはどうすか→Runkitでテスト用のコードを無理生やすなんて事が言われていました。
2 依存性の高いアクションをどうするか？
アクションはユニットテストの対象にならない(リクエストなどに依存する)
モデルに処理を集中すべし
テストデータを返してくれる抽象クラスがあるといい→FAKE
正しいものを組み合わせると正しく動くとは限らない
レガシーコードはテストのないコード(^^;)
