リフレクションや魔法のアノテーションがないのであればpublicにすることとなる。これはテストのためだけに設計が歪んでしまっているので避けるべきものである。付けてテストすればいいのではとも思わなくもないが、本来不要なものが外に見えてしまっているのはインターフェースの設計者からは反対意見も出るようだ。最小限のコストで最大限の効果を出したいから単体テストの考え方/使い方は、良いテストケースの構成要素に「最小限のコストで最大限の効果を出すこと」を挙げている。テストを書く目的はテストを書くことではなくて別のところにあって、その恩恵を受けるための考え方として至極真っ当だ。その恩恵はビルド時間やケースの修正時間などにあり、それを総合的に良いものにしていけるようにしたい。関数のテストが被るのはエコではないと思う。実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちるこの意見が一番多い気がする。単体テストの考え方/使い方にも末尾にアンチパターン集というのがあって、アンチパターンとしてこの理由で述べられている。そこでは実装の詳細が漏れ出したテストはすぐに落ちる偽陽性を生みやすく、その結果テストに対する不信感を醸成してしまうので避けようという主張だ。観察可能な振る舞いにのみテストせよと言われている。関数をテストしていたらその変更の都度テストが落ちることとなり、その修正がコストになってくるというのもある。関数にテストを書きたくなったらそもそも設計がおかしい」というのもあった。テストが書きたくなるほどのロジックが詰め込まれているのは、もっと疎結合に作れる余地がありそうというのは感覚的には分かる。関数にテストを書きたくなったらそもそも設計がおかしいから、そちらを直す」には反論できる余地があるとも思う。実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちるが、対処法はあるこれは程度の問題と工夫の問題でもあると思う。耐性が落ちることは悪いことなのかまず、リファクタリングの耐性が落ちることで頻繁にコードが落ちて不信感を産むことや、リファクタリングをしにくくなってリファクタリングに対するモチベーションが下がってしまうというのは分かる。「外部的振る舞いを保ちつつ、内部構造を改善する」という意味でのリファクタリングがされる場面は、新規開発やバグ修正に比べたらする機会は多くないと思っているので、そのコストは頻繁に発生しないと思っている。していることがほとんどだと思うし、副作用があったとしてもスコープがちぎられている関数であるので修正も容易のはずだ。数は多くなるのかもしれないが、直していける範囲だと思う。頻繁に落ちると言っても自分の変更をレポジトリにPUSHするときにCI回していれば気付けるし、自分起因でのfailだとコードやテストに対して不信感も抱かないと思う。そのコストが生まれるからリファクタリングしにくくなるという問題は残り続ける。関数のテストはリファクタリング時は消して、再構築してもいいのではと思った。関数のテストが落ちた場合は最悪消しても良いのを最初に合意しておくのも手だと思う。「落ちるテストによって行動が制限されたくない」という願望も含んでの主張だとは思うのだが、元々足される必要のないテスト(自分は必要あると思っているけど)がされていたと考えたら簡単に消せるのではないのだろうか。消して作り直せばいいのである。意識していればケースは簡単に作れると思う。private関数を作れた時点でテストコードはprivate関数そのものを作るに比べると簡単に作れると思う。網羅するテストを公開関数から流すのはケース作りが大変ではないかまたテストの網羅性を重視するのであれば公開関数だけをテストする方がリファクタリングへの耐性が落ちると思う。分岐に入るためのテストケースを作ったり、どうにかして実現させるためのモックを用意するのが大変だと思う。テストデータを共通化させるとその変更で他のテストが落ちるようになったり、ソースコード本体に手を入れたときにテストケースのどの部分を直せばテストが通るのかは内包するprivate関数のソースコード全体を読んで考えなければいけないので手間だと思う。これはそもそもホワイトボックステストをすべきかという話にも飛び火するのでこれ以上はあまりしないが、ホワイトボックステストした方が良い場合はあるのでその場合は主張として弱くなると思った。関数にテストを書きたくなったらそもそも設計がおかしいとは限らないと思うこれに関しては、要件そのものが複雑で一つの手続きが長いという場面はザラにあると思うので、「設計がおかしいから」とは一蹴できないと思っているし、そのような要件でテストをどう書くかを自分は議論したい。SRPを徹底して分割したとしても、その関数が再利用されるものであるならば良いがそうでないならテストのためだけにpublicにしたとも言える様な状況なので、それはそれでどうなのかとも言いたくなる。設計がおかしいことへのシグナルとして捉えるのは大いに賛成だ。関数のテストが被るのはエコではないこれはとても納得するし、真っ向からは反論できない。後述するがテストにドキュメントや例示としての役割を持たせるのであれば、役割が違うのでテストが重複するのも良いのではないかと思っている。関数のテストをしなくてもいい」への反論を書いてはきたが、今度はしたい理由について語ろうと思う。お守りとしてのテストここでお守りと書いたのは効果が確約されているわけではないというニュアンスを含めたかったからだ。private関数にテストが不要という意見の裏には、小さい関数をテストしても効果は限定的でコスパが悪いというのが含まれているのだろうが、それは納得している。「最小限の労力で最大の成果を」だ。開発者が自分の書いたコードの正しさを示し、それをテストコードの実行をソースレポジトリとCIの起動ログに残せるのは、自分達が安心感を得るという点ではとても効果的だと思う。自分はこの安心感というのは馬鹿にならないと思っていて、安心感があることで他の問題が起きた時の原因の切り分けがしやすくなる。それがソースと記録に残るのはとてもありがたい。ドキュメントとしてのテストテストは一番信用できる仕様だ。表現してくれているのはテストだと思う。テストはドキュメントだと思う。している関数の場合、どのような入力と出力になるのかが実際に実行しなくても分かるのはとてもありがたい。実際に実行してその値をキャプチャするのはとても大変だ。その例示があるだけで、既存コードの改修や読解をしないといけないときはとても助かる。関数においても言えることだ。何かで書けばいいのかもしれないが、先に述べた様にコメントは機械的には信用できないのでやはりテストがあるのが嬉しい。関数へのテストをドキュメントで行えてしまうのである。するのは正直これまでは気が引けていた。関数にもテストを書くようになるきっかけになるように思っている。皆さんの温度感はどうなんだろうと思って聞いたのが冒頭のツイートである。関数にテストを書くな」か「ケースバイケースな議論だ」となっていると思う。ケースバイケースな議論なのは自分も分かった上で書いているので、どうしてわざわざ話に出したかを最後に書こうと思う。関数にテストを書くべきではない」があると思う。テストの教科書や偉い人はそう言っているからだ。「べき」を下地においてケースバイケースという言葉で片付けていると、実務上の意思決定は「教科書」「元々のコーディング規約や慣習」「偉い人」「多数派」によって決まってしまうこともあると思う。関数にテストを書いても良いよ」という風に優しく言われたいと思って書いた。個人開発ならケースバイケースとして好きにすればいいと思う。testingでexampleを書く」だと思う。ソースコードはこちらです。このサイトはGatsbyで作られています。