覚書
- .rspecを変更してテストの実行結果の画面をカスタマイズする
(例)
--format documentation
自動化テスト
自動化テストは機能が正しく実装されたことを確認するためのもの。 「不安をなくす(確実に動くことを確認できる)」「実装を追加したり変更したりするときにも壊さないようにする(変更後に何か壊れたとしてもすぐに気づける)」などがテストのいいところだそうです。
とても大事そう、便利そうなのはよくわかるけど、自分で書けるようになるのはとても苦戦しています。でも、少しわかってきた気がします。(気のせいだったら悲しい)
テストのレイヤー
テスト | 特徴 | |
---|---|---|
↑ユーザ | システムテスト | エンドトゥエンド、UI、遅い、壊れやすい |
統合テスト | 機能同士のつながり、ユニットテストのカバー | |
↓開発 | ユニットテスト | 局所的、早い、信頼性高い、設計開発 |
システムテスト
ユーザーの実際の動きを想定したテスト。要件通りになっているかを確認する。
統合テスト
機能同士やAPIなどの連携についてのテスト。単体では動いても連携するとバグが起きることもある。
ユニットテスト
modelやhelperの機能をテストする。 1つのテストで1つの機能のテストをする。
- ハッピーパス:理想とする動作
- 特殊ケース:特殊な条件、エッジケース
- 例外:エラーが起こるとき
- 流れとロジック:プログラムの流れや条件分岐
- そのほか:他に必要なテストはないか
ユニットテスト→統合テスト→システムテストの順に書いていく。
テスト駆動開発の基本
流れ
- 失敗するテストを書く
- テストが通るように実装コードを書く
- リファクタリングする
テスト難しい
本を読んだりコードを見たり写したりする→できる気がする→やってみる→できない→本を読んだり・・・
をここ数日繰り返してるけど、自分こんな頭悪かったっけっていう気持ちが湧いてきて本当にたまらない感じ。(や、でも、確かに賢くはない)
でも書けるようになると楽しいらしいです。
毎日少しでもいいからやっていくしかない。 あと、もっとたくさん人のコードを見て回って、テストの考えかたも書き方も感覚的なものも掴んでいきたいです。
参考
Ruby on Rails チュートリアル:実例を使って Rails を学ぼう
Everyday Rails… by Aaron Sumner et al. [Leanpub PDF/iPad/Kindle]