目次
テストできるコードの書きかた
この文書について
- "Guide: Writing Testable Code" の日本語訳です
- 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか...
- TODO: 各 Flaw のリンク先も訳す
Misko Hevery
コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。
このガイドをつくるにあたって、着想をくれると同時にたくさんの時間を割いてくれたみんなに多謝:
まずいのその1: コンストラクタがやりすぎ
→ WritingTestableCodeFlaw1ConstructorDoesRealWork
あぶない予兆
- new キーワードがコンストラクタの中にあるか、メンバ変数の宣言にある
- スタティックメソッドがコンストラクタで呼ばれているか、メンバ変数の宣言で呼ばれている
- メンバへの代入以外のなにかが、コンストラクタで行われてる
- コンストラクタを抜けたときに、オブジェクトが完全に初期化されていない (initialize メソッドがあったら要注意だ)
- 制御フロー (条件分岐やループ) がコンストラクタの中にある
- ファクトリやビルダーをつかわないで、複雑なオブジェクトのグラフをつくってしまっている
- 初期化ブロックを加えたり、使ったりしてしまっている (?)
まずいのその2: 深い仲になってしまっている
→ WritingTestableCodeFlaw2DiggingIntoCollaborators
あぶない予兆
- 渡されたオブジェクトをそのまま使っていない (他のオブジェクトにアクセスするためだけに使われてる)
- デメテルの規則に反している: メソッド呼び出しが、オブジェクトをまたがって連鎖してる、つまり ドット (.) がひとつ以上あるということ。 (訳注: 例としては、ab.cd.ef.gh() みたいなかんじかな)
- あやしげな名前: context, environment, principal, container, とか manager みたいなやつ。
まずいのその3: 脆いグローバルな状態とかシングルトンとか
あぶない予兆
- シングルトンを追加してたり、使ってたりする
- スタティックなメンバ変数や、スタティックなメソッドを追加してたり、使ってたりする
- レジストリを追加してたり、使ってたりする
- サービスロケータを追加してたり、使ってたりする
まずいのその4: クラスがやりすぎ
あぶない予兆
- 役割を要約してみると、クラス名に and が含まれてしまってる
- チームに新しいメンバーが入ってきたときに、彼がクラスを読んだりすばやく理解できない
- あるメソッドでしか使っていないメンバ変数があるようなクラス
- 引数にだけ適用されるスタティックメソッドがあるようなクラス
