fix

src/contents/20230825-oreha-private-func-nimo-test-kaku/index.md

@@ -39,6 +39,8 @@ private 関数をラップして public にしたバージョンを `ForTestIfYo
 
 [単体テストの考え方/使い方](https://amzn.asia/d/dZahYWL)は、良いテストケースの構成要素に「最小限のコストで最大限の効果を出すこと」を挙げている。テストを書く目的はテストを書くことではなくて別のところにあって、その恩恵を受けるための考え方として至極真っ当だ。その恩恵はビルド時間やケースの修正時間などにあり、それを総合的に良いものにしていけるようにしたい。
 
+public な関数と private な関数のテストが被るのはエコではないと思う。
+
 ### 実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちる
 
 この意見が一番多い気がする。[単体テストの考え方/使い方](https://amzn.asia/d/dZahYWL)にも末尾にアンチパターン集というのがあって、アンチパターンとしてこの理由で述べられている。
@@ -51,11 +53,11 @@ private 関数をラップして public にしたバージョンを `ForTestIfYo
 
 昨日のツイートについた意見としては 「private 関数にテストを書きたくなったらそもそも設計がおかしい」というのもあった。テストが書きたくなるほどのロジックが詰め込まれているのは、もっと疎結合に作れる余地がありそうというのは感覚的には分かる。
 
-## private 関数をテストしたいことはおかしくないと思う
+## 反論したいところだけ反論すると
 
 一方で 「実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちる」「private 関数にテストを書きたくなったらそもそも設計がおかしいから、そちらを直す」には反論できる余地があるとも思う。
 
-### 実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちる
+### 実装の詳細を知りすぎるのはリファクタリングへの耐性が落ちるが、対処法はある
 
 これは程度の問題と工夫の問題でもあると思う。
 
@@ -79,10 +81,16 @@ private 関数をラップして public にしたバージョンを `ForTestIfYo
 
 またテストの網羅性を重視するのであれば公開関数だけをテストする方がリファクタリングへの耐性が落ちると思う。分岐に入るためのテストケースを作ったり、どうにかして実現させるためのモックを用意するのが大変だと思う。テストデータを共通化させるとその変更で他のテストが落ちるようになったり、ソースコード本体に手を入れたときにテストケースのどの部分を直せばテストが通るのかは内包するprivate関数のソースコード全体を読んで考えなければいけないので手間だと思う。これはそもそもホワイトボックステストをすべきかという話にも飛び火するのでこれ以上はあまりしないが、ホワイトボックステストした方が良い場合はあるのでその場合は主張として弱くなると思った。
 
-### 「private 関数にテストを書きたくなったらそもそも設計がおかしいから、そちらを直す」への反論
+### private 関数にテストを書きたくなったらそもそも設計がおかしいとは限らないと思う
 
 これに関しては、要件そのものが複雑で一つの手続きが長いという場面はザラにあると思うので、「設計がおかしいから」とは一蹴できないと思っているし、そのような要件でテストをどう書くかを自分は議論したい。また、例え[SRP](https://xtech.nikkei.com/atcl/nxt/column/18/02319/010500002)を徹底して分割したとしても、その関数が再利用されるものであるならば良いがそうでないならテストのためだけにpublicにしたとも言える様な状況なので、それはそれでどうなのかとも言いたくなる。もちろん設計がおかしいことへのシグナルとして捉えるのは大いに賛成だ。
 
+### public な関数と private な関数のテストが被るのはエコではない
+
+これはとても納得するし、真っ向からは反論できない。
+
+ただ、後述するがテストにドキュメントや例示としての役割を持たせるのであれば、役割が違うのでテストが重複するのも良いのではないかと思っている。
+
 ## private 関数にテストをしたい理由
 
 さて、「private 関数のテストをしなくてもいい」への反論を書いてはきたが、今度はしたい理由について語ろうと思う。