- テストしにくいコードをテストする方法教えて下さい
848 ：デフォルトの名無しさん[]：2016/12/28(水) 00:11:54.87 ID:zQENRRN7 - privateメソッドに対してテストをしたくなっったら
それはクラスが肥大化してる証拠だよ。
まず前提としてprivateメソッドなんてものは
ほとんど必要ありません。
長い処理があったとして、その中で汎用的な処理を
抜き出していったら、コードは短くなります。
短いのだからprivateな関数にするまでもありません。
それでもprivateメソッドが残ったとしたら
それはヘルパーメソッドとして別クラスに分離する。
別クラスの関数を呼ぶのだから、必然的にそのメソッドはpublicになる
そうすりゃそのメソッドだけでテストかけるだろう？
privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
|
- テストしにくいコードをテストする方法教えて下さい
860 ：デフォルトの名無しさん[sage]：2016/12/28(水) 23:06:39.02 ID:zQENRRN7 - >>849
> privateにすべきかどうかは、外部から隠蔽すべきかどうかのみによる。
ヘルパークラスを作れば外部から隠蔽しない理由になるだろ
privateのままにしておくからテストできないんだよ。
そういうものは隠蔽すべき理由を無くしてpublicにしてしまえと言ってる。
|
- テストしにくいコードをテストする方法教えて下さい
861 ：デフォルトの名無しさん[sage]：2016/12/28(水) 23:10:39.71 ID:zQENRRN7 - 言っておくけどprivateのものを処理を全く変えずにpublicにしろって話じゃない。
テストをしたくなるほどprivateメソッドが複雑になるのであれば、
そのprivateメソッドをヘルパー関数の形で汎用化しろって話。
そうすれば、対象のクラスそのものではなくてヘルパークラスのみで
テストできるようになる。そしてクラスはシンプルになる。
|
- テストしにくいコードをテストする方法教えて下さい
862 ：デフォルトの名無しさん[sage]：2016/12/28(水) 23:18:43.37 ID:zQENRRN7 - >>857
> そのような場合は、リファクタリング後にテストを変更するのでは？
これも関連する話。まずリファクタリング後にテストを変更するのは当然
まず対象のクラスに対してテストを書く。そしてリファクタリングをする。
この時、汎用的な処理をヘルパークラスや親クラスとして抽出する。
ここまででテストを変更することはないが、
次に対象のクラスにあったテストのうち、ヘルパークラスや親クラスに分離したものは、
対象のクラスのテストではなくて、ヘルパークラスや親クラスのテストとして移動する
ヘルパークラスや親クラスでテストしている内容を、
それを使用している対象クラスでもやる必要はない。
具体的に言うと、あるモデル、例えばUserモデルクラスにsaveメソッドを作ったのであれば
そのsaveメソッドのテストを書くのは当然だが、そのsaveメソッドが親クラス
（例えばRailsで言えばActiveRecord::Baseクラス）にあるものならば、
Userモデルクラスでsaveメソッドのテストをする必要はない。
こうやってヘルパークラスや親クラスに処理を移動して、それに対するテストを書くことで
それを使用している部分ではテストが不要という状態を作り上げることが重要
|