fix

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

@@ -25,6 +25,8 @@ isProtect: false
 
 さて、private 関数にテストをしなくていい理由をまず考えてみよう。昨日のツイートへの反応だったり、自分がこれまで言われたり調べたり、[単体テストの考え方/使い方](https://amzn.asia/d/dZahYWL) に書かれていたことだ。
 
+![book](./book.png)
+
 ### private 関数をテスト可能にするために export することはおかしいから
 
 いまは In-source testing を忘れて考えると、private 関数をテストするには多くの場合は public にする必要がある。リフレクションや魔法のアノテーションがないのであればpublicにすることとなる。これはテストのためだけに設計が歪んでしまっているので避けるべきものである。
@@ -53,11 +55,17 @@ private 関数をラップして public にしたバージョンを `ForTestIfYo
 
 #### 耐性が落ちることは悪いことなのか
 
-まずリファクタリングの耐性が落ちることがそんなに問題なのだろうかと思う。そもそも「外部的振る舞いを保ちつつ、内部構造を改善する」という意味でのリファクタリングがされる場面は、新規開発やバグ修正に比べたらする機会は多くないと思っているので、リファクタリングの耐性が落ちることは事実として認めつつ、そのコストはそこまで大きくないのだろうかと思っている。特にprivate関数は In と Out がはっきりしていることがほとんどだと思うし、副作用があったとしてもスコープがちぎられている関数であるので修正も容易のはずだ。ただ数は多くなるのかもしれないが、機械的に直していけると思う。
+まず、リファクタリングの耐性が落ちることでリファクタリングをしにくくなって、リファクタリングに対するモチベーションが下がってしまうというのは分かる。悪いことだ。
+
+けど、「外部的振る舞いを保ちつつ、内部構造を改善する」という意味でのリファクタリングがされる場面は、新規開発やバグ修正に比べたらする機会は多くないと思っているので、そのコストは頻繁に発生しないと思っている。またprivate関数は In と Out がはっきりしていることがほとんどだと思うし、副作用があったとしてもスコープがちぎられている関数であるので修正も容易のはずだ。数は多くなるのかもしれないが、直していける範囲だと思う。
+
+ただそのコストが生まれるからリファクタリングしにくくなるという問題は残り続ける。なのでprivate 関数のテストはリファクタリング時は消して、再構築してもいいのではと思った。
 
 #### private 関数のテストの priority を下げてはどうか
 
-またリファクタリングへの耐性が落ちることを問題視するのであれば、public関数のテストが通っていて、private 関数のテストが落ちた場合は最悪消しても良いのを最初に合意しておくのも手だと思う。おそらく「落ちるテストによって行動が制限されたくない」という願望も含んでの主張だとは思うのだが、元々足される必要のないテスト（自分は必要あると思っているけど）がされていたと考えたら簡単に消せるのではないのだろうか。
+リファクタリングへの耐性が落ちることを問題視するのであれば、public関数のテストが通っていて、private 関数のテストが落ちた場合は最悪消しても良いのを最初に合意しておくのも手だと思う。おそらく「落ちるテストによって行動が制限されたくない」という願望も含んでの主張だとは思うのだが、元々足される必要のないテスト（自分は必要あると思っているけど）がされていたと考えたら簡単に消せるのではないのだろうか。
+
+そして決して作り直せばいいのである。private関数を作り直すときに、しっかりと IN/OUT を意識していればケースは簡単に作れると思う。private関数を作れた時点でテストコードはprivate関数そのものを作るに比べると簡単に作れると思う。
 
 #### 網羅するテストを公開関数から流すのはケース作りが大変ではないか