Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
レガシーコード改善ガイド (Object Oriented SELECTION)
目次
- 目次
- はじめに
- Unit testは速いほうが良い
- Unit testは安定していないといけない
- Unit testは環境に依存してはいけない
- Unit testが外部のシステム(DBや通信による別のアプリ)に依存してはいけない
- 公開APIを使ってUnit testを作成すべき
- 二箇所以上の場所で使われていたらテストする
- テストコードの本体は読んで一瞬でわかるように、明確なテストを書く
- テスト関数名は長くても良いので明確にわかりやすい名前をつける
- テストはメソッド毎ではなく、挙動や状態でテストする
- テストコードはgiven, when, thenで分類する
- 多少重複があってもテストは愚直に書く
- エラーメッセージはわかりやすく書く
- Builderパターンで初期オブジェクトを作り、その一部を変えてテストを書く
- 参考資料
- MyEnigma Supporters
はじめに
これまでも各言語のUnit testのフレームワークなど、
Unit testの作り方を説明した記事はまとめてきましたが、
どのような (どのように)Unit testを書くべきか(設計すべきか)という資料は
あまりまとまっていない気がしたので、
これまで自分が読んで来た冒頭の書籍や、
自分の経験を元にまとめておきます。
続きを読む