小論文と小籠包は似ている。同じようなことを考えている人がいるはずだと考えて検索したら、大量にそのようなツイートが出てきた。『うなぎなう』と同じくらいあるのではないか。つまり小籠包はうなぎだということがわかった。うなぎ料理といえばひつまぶしだ、というかそれくらいしか知らないが、つまりひつまぶしのうなぎじゃない部分が小論文に相当するわけか。かける汁が小論文なのだろう。ここで冷静になって考えてみると、小論文が汁で小籠包がうなぎである可能性もあった。『包』という漢字に着目すれば、汁がうなぎを包んでいると考えるのが妥当だから、小籠包が汁で小論文がうなぎということになる。小論文といえば皆に嫌われる課題の代表格だが、うなぎは皆に好かれている。どうしてこのような差が生まれてしまったのか。うなぎは美味しいが小論文は食べられないというのが原因の一つとして考えられる。つまり小論文を美味しく食べることができれば皆が小論文を好きになり、小論文とうなぎは同一の存在に近づく。小論文を書くのは紙で、紙を食べるといえばヤギだ。しかし実のところヤギに紙を食べさせるのはあまりよろしくないらしい。やはり小論文を食べるのは難しいか。しかし希望は残っていた。小論文を書く場所は紙とは限らない。べつにWordでもテキストファイルでも、内容が小論文であれば小論文であることには違いあるまい。近年は新型ウイルスによる感染症を避けるため授業のリモート化が進められているから、それに合わせて小論文が電子化されるのも十分ありうる話だろう。しかし電子化したものを食べるのは紙を食べる以上に困難だ。やはり難しいか。ここで、電子化したデータは様々な形式でエクスポートできるということに気づいた。つまり、食べられる形式で小論文をエクスポートすれば小論文を食べることができるようになるということだ。どこかの童話に出てきたお菓子の家みたいに、お菓子の小論文というものを考えれば、小論文を食べることが可能になる。厳密にはうなぎはお菓子ではないのだが、うなぎパイというお菓子があるので、まあ問題なかろう。しかし、400字程度の小論文でもお菓子にするのはそれなりにコストがかかる。たとえばバースデーケーキを例に考えると、お誕生日おめでとうの10 文字程度しか情報を持つことができない。したがって小論文ケーキはバースデーケーキのおよそ40倍コストがかかってしまう。あまりにも値段が高騰してしまった。近年はうなぎの値段が高騰しているから、それで適正かもしれない。

Permalink | 記事への反応(4) | 19:53

2020-12-20

■プライベート メソッドをテストすべきか

「すべきでない」というのがたぶん多数派。

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ

ほとんどの場合、プライベートメソッドをテストする必要はありません。プライベートメソッドは実装の詳細です。
プライベートメソッドがある場合は、パブリックメソッドを見つけて、そのメソッドに対してテストを記述します。
単体テストを記述するためのベストプラクティス - .NET | Microsoft Docs

「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。

しかし「プライベート メソッドのテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

「プライベートメソッドをテストしたい場合はある。でも簡単にはテストができない。それでもテストするか。どうやってテストするか」

が問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
例えそのクラスがprivateメソッドで依存関係があっても。
コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)

メソッドがプライベートかパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドをテストするかどうか？まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
"テストを書くべき"と"上位層からの可視性"は直交する概念
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)

プライベート メソッドのテストがしやすい言語での意見。

RustやGoではプライベートメソッドに対するテストが簡単にできる。

そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。

Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。
概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。
Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに
assertionチックにprivateメソッドのすぐ下にテスト書きたい
ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)