我看了這篇文章重構細節
http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
而且我困惑約
「代碼開發重構的背景下並不需要新的 測試！」
例如在重構過程中，我希望將一些計算移動到一個新的類中，這個類計算了我的階乘因子，並且使用這個類來計算一些用戶特定的細節。在我的要求中，我永遠不會寫這個類，它只是在重構過程中創建的。但是，當我用測試來覆蓋這個班級以保證預期的行爲時？據我瞭解，我絕不會用測試來覆蓋這門課，或者我錯了？
你是對的。
有兩種方法可以考慮重構，其中包括兩組稍微不同的技術。
第一個是做冪等變化：修復一個方法內的一個小東西，以便最終結果不會改變。正如文章所述，這不需要改變。
第二個（更有趣的IMO）涉及到創建新的類，改變使用的設計模式，有時對類（或類）結構進行巨大的改變。當您沿着行進時，此確實需要更新測試。
讓我提出一個不同的解釋：對我來說，你需要測試的至少兩個層次：
單元測試，用於測試的方法。重構的生產代碼的時候，要遵循代碼修改這些測試會改變（他們甚至可以在變化之前完成，使用TDD來驅動它）
驗收測試（可能使用一個集成測試框架，像FITnesse或JBehave，或純JUnit如果不是） - 這些測試是高級別驗收標準，它們應該在重構過程中更改而不是，並且在結束時仍然通過。事實上，他們是你的利益，你的證明成功的重構。篡改代碼，不加思考地修改代碼，並且在一天結束時，您的驗收測試仍然應該通過。如果他們這樣做，你很好走。如果不是，那就意味着你已經破壞了一些東西（或者你的測試首先是錯誤的）。
（目前正在測試的另一個層面是真實需要：系統測試，或集成測試，但它們超出了問題的範圍）
我認爲，正確的TDD我應該寫小/快速測試。並且經常運行它們。但我認爲接受測試並不是那麼快，而且網站的一系列接受測試會很慢。我認爲在重構過程中單元測試的變化是不可避免的。我沒有讀過Kent Beck的TDD，所以我對此有了純粹的認識 –
所以現在我已經閱讀了你已經鏈接的文章（我只是第一次快速瀏覽它），而作者選擇的方法是不要細粒度的單向測試，但基本上只有驗收測試。我自己對這種方法有些不適應，我更喜歡在重構期間改變我的測試（特別是因爲我嚴重依賴於模擬） - 更改測試可能被視爲重構的一部分。 – Guillaume
你說得對，驗收測試需要更多時間來編寫，但它們對於記錄系統並直接將用戶需求轉化爲實際代碼非常有價值。事實上，我個人的TDD方法是：寫入驗收測試，與用戶驗證，然後啓動單元-TDD（基本紅綠重構週期），最後檢查我的驗收測試通過。如果您願意，可以將兩個嵌套的TDD週期排序在一起:)而且我的原始驗收測試給了我一個很好的方式來知道我完成了我正在處理的故事/任務。在任務完成之前必須將任務交給其他人也很好。 – Guillaume