今天凌晨作者跟我有進行一些交流跟討論。
我摘錄一下我這邊提供的一些想法跟意見，給大家參考。
▍兩個面向討論
① 首先是 private class 存在的必要性與目的，我在實務上 幾乎不會用到 private class，尤其是 TDD。職責大到要用一個class來放，就不會是 private 等級的。而且當很熟悉重構的工具跟手法，extract class 出去就自然變成另一個類的 public function. ( class 可以是 internal)
② 再來是，當你寫下測試程式時，它的目的是拿來測產品代碼，還是拿來描述需求情境。（沒有對錯，不同目的會寫出不同風格，這兩者實務上也都會發生，不互斥
▍做法
文中提到的三種做法，實務上如果是正常的 extract class 又不想暴露給 assembly 之外存取，internal + [InternalsVisableTo] 是標準做法。
但如果只是為了去除依賴，方便測試，該方法或依賴不到一個物件職責的等級，或是針對 legacy code 補上 isolated unit test，那我的首選是第三種，protected + extract and override。
protected 的暴露，副作用跟影響範圍遠小於 internal class。
所以一跟三的選擇，僅在於「是不是該抽出一個類」，依據這來決定一或三。
但二的反射問題就很多了，一來測試難以理解。二來測試看不出來意圖。三來，private 應該可以被任意修改。就更別說反射本身對字串的脆弱性。
▍重點
其實重點還是在，測試是用來描述外部使用情境，一但你在測試裡面用反射取得private class，那就代表著，外面在這「使用情境」也該用反射去呼叫內部類別的方法。
而這一點，就是暴露了實際代碼實作的細節在測試中，用的人，知道越少，代表你的API越簡單好用。
因為你原本的重點，變成是在測代碼，不是在描述需求的使用情境。
單元測試，應該是物件的使用說明書。你的測試就是在模擬或說明，如果這樣用，會發生什麼事。
而這就是我最開頭講的，得很清楚，目前自己寫的測試是在幹嘛，不是為了測試而測試。
https://dotblogs.com.tw/…/why-you-should-not-write-unit-tes…
那樣測試才會穩定，才會發揮作用，才能當 spec 或說明書 或 living documentation 等級的產物。
用微波爐來當例子，你該怎麼幫微波爐寫 test cases?
如果微波爐是個物件，你不該用特殊方式拿到裡面的某個粒子發射器，然後說明粒子發射器如果碰到啥，就怎樣怎樣。
對看手冊的人，會覺得這是啥小。
而且實作細節是會改變的，但使用情境通常不變。
例如，我把微波爐的電源透過轉接頭轉成220v，不影響你怎麼用微波爐，但那個電源可能就是你原本的private class。
那樣實作改變，你的測試用反射的部分就會壞掉。
▍結論
你得到的好處是：「偵測到有東西跟你原本想要的不一樣。」
但這好處不一定有價值，甚至可能是種困擾。
因為你不知道，它影響到了哪些真實的使用情境。而我們只在乎別人會怎麼用，跟該怎麼用。
所以，它 work, 但可能是種不必要的暴露跟干擾。
花時間在那上面，是自己爽的。
可以做到，不代表應該那麼做。
#單元測試實戰
#願意問_我就樂意講
※ 謝謝 林暐翰 的提問，讓我能借花獻佛，分享我的想法給大家參考。
測試用api 在 postman 好用API 測試工具 - Jw的學習大小事 的推薦與評價
Postman. 模擬HTTP Request 來測試API 的好用工具，包含幾種HTTP 請求方式： GET 、POST、PUT、DELETE。 安裝. 安裝版下載網址 ... <看更多>