[譯] 爲何TDD會改開發人員的生活

原文：medium.com/@raphaelyos…

意譯。

重構時給你信心

從經驗看，即便集中精力進行重構，即使只是給一個變量進行了賦值也可能致使不少問題。沒有測試套件，你就不能測試他們。

強制編碼必須可測試的方式設計——能夠促使你的設計更聽從SOLID原則

[Route("api/[controller]")]
[ApiController]
public class UsersController : ControllerBase
{
  [HttpGet]
  public ActionResult<UserResponse> Get(int id)
  {
    var domainUser = UserRepository.GetBy(id);
    var responseUser = UserResponseParser.Parse(domainUser);
    return Ok(responseUser);
  }
}
複製代碼

在大多數狀況下，靜態類是邪惡的。若是是靜態類，則它們不會被注入，這意味着它們不容易被替換。

咱們沒法對此控制器進行單元測試，由於測試將調用數據庫，若是您先編寫測試，則不會發生這種狀況。

長遠看會開發更快

爲您提供一種在幾秒鐘內從新測試應用程序的簡便方法

You will often hear, we have no time to write tests, we have no time to do it right. So do you have time to do it twice? The point is if you write a program that does not have automated tests, that will quite likely grow into the point it becomes the spaghetti monster developers take long to fix bugs, as the code is hard to understand and small changes cause magical side-effects.Then the development team will start asking for a rewrite, if they don’t apply TDD the cycle repeats.

你常常聽到，咱們沒時間寫測試，咱們沒時間作正確的事。因此你有時間作兩次嗎？（ps: 問了做者，做者的意思是有些開發人員由於作事匆忙，並以此爲藉口不遵循良好的開發原則致使代碼愈來愈難以維護，最後不得不重構）。關鍵是若是你編寫一個沒有自動化測試的程序，他極可能會成爲一個意大利麪怪獸同樣，開發人員花很長時間來修復bug，同時代碼很難理解，小的變化會致使神奇的反作用。 若是他們沒有應用TDD循環重複，因而開發團隊將開始要求重寫。

那麼編寫測試首先會減慢開發速度嗎？要看怎麼理解。沒有寫測試，你何時知道你何時完成了開發？ 你有信心它有效嗎？ 它是否涵了蓋邊緣狀況？在嘗試擴展應用程序時，若是你能擴展它而且知道你沒有破壞之前的行爲，那不是很棒嗎？

開發週期會更快，從長遠來看，隨着TDD成爲習慣，速度也不會那麼不一樣。（ps:問了做者，沒有TDD，一個任務可能須要2小時，若是你第一次使用TDD的話可能須要6小時，但若是你熟練的話，可能剛好也是2小時。關鍵點在於，在修改代碼後，自動化測試會幫你節省大量手動迴歸的時間）

還要記住，與編寫新軟件相比，咱們做爲開發人員的大部分時間都是維護和擴展，所以咱們必須對其進行優化。

Minimise YAGNI (You aren't gonna need it) — As developers have clear goals to know when the task is done.

Having a test suite that gives you clear goals so you know when you are finished reduces the guess effort. What will happen on this condition? Instead of wonder, you write a test and define the behaviour you want from it.
It will avoid a lot of unnecessary code.

維護成本下降

如何開始

是否如今就開始寫測試用例呢？並非！ TDD首先由Kent Beck提出，他爲此指定了三條規則：

• You shall not write production code other than to pass a failing test
• You shall not write more of the production code than necessary to pass that failing test.
• You shall not write more of the test than to make it fail for the right reason.

ps: 專門搜了一下，tdd三原則是 uncle bob 提出的，出處：link1, link2。

• 定律1、在編寫不能經過的單元測試前，不可編寫生產代碼。
• 定律2、只可編寫恰好沒法經過的單元測試，不能編譯也算不過。
• 定律3、只可編寫恰好足以經過當前失敗測試的生產代碼。

其餘資料

• sites.google.com/site/uncleb…
• martinfowler.com/articles/is…
• www.cnblogs.com/haonanren/a…