機器學習 單元測試
沒有單元測試，您怎麼稱呼重構？
任何人？
是。 這是一個技巧問題，不是嗎？
沒有單元測試的重構不稱爲重構。 稱爲更改代碼 。 它甚至可以被稱爲破壞代碼 。
隨時添加測試
當您需要更改未經測試的代碼時，添加單元測試很有用。 您實際上可以添加兩種類型：
- 一個顯而易見的用例–您已經瞭解了代碼，並且可以看到它可以處理的用例，它很好而且很簡單
- 表徵–您不知道代碼的含義，但是可以通過它運行一些數據，捕獲輸出，然後在單元測試中編寫一個斷言，指出我將來運行此命令時的輸出應爲不管這是什麼
不幸的是，通過重構複雜的舊代碼，後者是您擁有的最佳工具。 儘管一旦確定了所有測試的黑盒，就可以對代碼進行一點剖析，添加用例驅動的測試，並最終將其置於控制之下。
如果我未經測試就更改了該怎麼辦？
您可以進行一些重構，尤其是使用IDE中的可用工具時，似乎並不能證明首先編寫測試是合理的。
幾個小時後，您可能會想– 是的，但是我把它弄壞了嗎？ 。 而且您的分支機構中的代碼已更改。.它可以通過所有當前的單元測試，但是否與master分支版本相同？ 我們需要退一步。
這是git可以拯救您的地方（可以使用其他源代碼控制，但是長大了：現在是2020年，請使用git ）。
- 保持分支機構的安全
- 回到`master`
- 使用缺少的單元測試創建一個新的功能分支
- 得到那些建築，然後合併
- 回到您的重構分支，然後重新建立基礎
即使您稍微更改了接口，該技術也將有所幫助，因爲在重新設置基準之後，您只需要調整一些測試代碼即可……或者至少可以預測。
如果您滑入master的測試通過了功能分支，那麼恭喜您。 如果不是，那麼您可能希望以不同的方式進行重構……儘管您可以調試它並修復向前。
如果您有新的疑問，則可以重複該過程並將更多的測試滑入master的頭中，並對它們進行重構。
如果很晚怎麼辦？
這就是git證明是Linus Torvalds的時間機器的地方。 我描述的過程可以應用於git歷史記錄中的任何提交 。 在進行大部分重構之前，先檢查提交，然後將單元測試添加到從那裏獲取的功能分支中。 讓它變成綠色。 然後cherry-pick是單元測試到之後的特性分支，看看它在當下的代碼。
TL; DR
- 您需要測試以支持重構
- 隨時添加
- 或追溯性地將它們添加到早期版本的代碼中，使用`git`倒帶
- 然後將通過原始代碼的測試與最新的重構一起使用
翻譯自: https://www.javacodegeeks.com/2020/04/the-unit-test-time-machine.html
機器學習 單元測試