我目前正在嘗試創建一些類來執行一些傅立葉變換。 我想通過先創建一些單元測試來完成它，然後構建基本功能。適用於私人方法的單元測試
這個問題是，那麼，我可以寫一個測試，看看算法是否工作，我知道預期的結果。然後我開始構建這個大算法，如果它能夠運行，我的單元測試就會通過。
我的問題在於，它不是真的TDD。因爲通常你會創建測試來測試一個類的一個非常基本的特性。現在我的課程基本上執行一個大算法，我不能測試算法的較小部分，因爲它們不是公開的（我總是被告知你永遠不想測試私有方法）。
你如何處理這個問題？
我看到2點可能的方式：
我最近一直在與「什麼是單位？」作鬥爭。這確實是一個棘手的問題。
如果您有理由相信FFT的子單元特別容易出錯，那麼可以調整邊界條件並打破私有方法免於使用的規則。
另一種說法相同的方式是子單元實際上是一個單元，它的服務被FFT使用，然後你沒有違反規則。
我想如果你不能測試你的算法的單個組件，或者代碼是非常緊密耦合的，或者代碼是非常程序化的。
您可能必須將您的代碼定義爲單位並將這些單位設置爲受保護的方法。只要該方法受到保護，它就會發送一條明確的消息，表明它不屬於API的一部分。
那麼如果你的類只有一個可測試的方法（根據你的測試公共方法的標準），那麼你別無選擇，只能測試該方法，對嗎？這並不意味着它不是TDD，而是 - 你當然可以測試各種各樣的輸入值。這裏的大部分工作將會發現有趣的價值 - 你的變換可能會失敗的邊緣情況是什麼？是否有任何無效輸入以及如何處理？
是否有某種方法可以對許多值進行算法驗證，例如調用已知良好的例程，使用一些關鍵的傅立葉相關標識，或者可能使用FFT來做multiplication？
無法獲得程序風格和不可能測試之間的聯繫。程序代碼可以被測試以及面向對象。 – zerkms 2011-04-17 08:25:07
@zerkms，我同意，但我是在背景下發言。在程序代碼中，有更緊密耦合單元的可能性更大。 （在這種情況下的過程）..我看到了代碼編寫的代碼，執行單元測試非常困難。 – 2011-04-17 09:51:48
你可能已經閱讀過了，但是如果沒有 - 我認爲這將是很好的建議閱讀：邁克爾羽毛，「與遺產代碼有效地工作」 – zerkms 2011-04-17 09:55:11