從管理人員到開發者，每個人都在說單元測試，但是卻很少有人執行。有關單元測試的好處相信大家也能例舉出一二，但很多時候，開發者面對自己的項目代碼卻無從下手。
Lurkerbelow在公司里是唯一執行單元測試的一名開發者，他深知單元測試帶來的好處，也積極提倡單元測試。他甚至與公司的管理層人員、開發者都討論過單元測試，但卻無人對此感興趣。 為了與開發人員形成一條戰線，Lurkerbelow甚至“被迫“提交了代碼審查（Gerrit）和持續集成開發（Jenkins）。
無奈之下，Lurkerbelow在 Stack Exchange發出上“求救”，拋出《“如何激勵同事進行單元測試？》的話題，引發了眾多開發者的關注，紛紛獻策。
對此，我們從中摘譯了幾個較為重要的觀點與大家分享，希望能引起大家的共鳴。
實質的文檔或許有幫助
jimmy_keen：我注意到幾乎很少有公司在談論TDD。人們更樂意看到最終結果。人人都說“編寫單元測試將縮短開發時間”，這是似乎是真的，但這并不足以讓人們相信。
我與你處在相同的位置（但不像你這么糟糕），開發者在代碼問題上都能夠自行解決（這里的代碼是指單元測試）。某個項目停止更新時，本地的調查自然就會更進，進而找出問題所在。
然后，當我們進行單元測試時，如果測試被通過了，大多數問題會出現在最新的、未測試的代碼中。如果不是，測試通常能夠發現問題（至少找出了正確的方向）。我們修復Bug，再進行測試。
一句話，如果發生類似這樣的情況，將會有超過2名開發者變成可TDD 測試愛好者（我們希望更多人參與）。
建議，你可以選擇TDDkata將使用測試作為首選方法。
根據任務的復雜程度，非測試方法進程通常較為緩慢，尤其是當增量編碼器需求發生更改時。
● Roy's string calculator
● Bank OCR
找出問題所在，“對癥下藥”
HLGEM：首先，要弄清楚為什么他們不喜歡寫單元測試。 通常嚴格的時間進程表是導致其最大的原因。
其次，現有的大型未測試的代碼基，編寫單元測試工作量巨大。因此，開發者本能認為：“這太麻煩了，我得跳過去。”
另一個原因可能是，他們骨子里認為測試是個好方法，但他們在如何寫測試上沒有信心，尤其是他們從未接觸過。究其根本原因，是開發者根本不會寫單元測試！
還有一大原因是，他們沒有看到這項額外的工作所帶來的好處（利潤）故放棄，即便是他們想提供這樣的服務。
那么，對于以上這些情況該如何處理呢？
Reason 1：向開發者展示案例，如何節省開發時間。
Reason 2：告訴開發者在一年內能編寫多少測試，代碼基覆蓋了多少比例。
算算這一年里他們寫了多少測試，明年他們依然愿意這么做。一旦他們發覺每天都會進步一點點，思想上就會潛移默化了，從而產生質的變化。
如果可以的話，把系統數據拉出來，讓他們知道在未經測試的代碼中有多少重復Bug？進行單元測試的代碼中又有多少重復bug？
Reason 3：培訓，讓開發者在培訓班中編寫測試。
Reason 4：這是問題的關鍵所在，首先，選擇一個痛點，比如在某個項目中這些Bug被多次返回。在上述過程中，向管理部門提出建議，如果他們在這個項目中進行單元測試，那就不會出現不想見而又偏又見到的代碼。
當然，作為開發人員，我們首先要學會自我管理。
寫好單元測試，學會重構很重要
ElYusubov：我想先說說TDD的好處。
從正常人類的角度思考，開發者都是以利益為主，因為他們不想進行工作意外的事情。單元測試意味著更少的工作；意味著與朋友相處的時間更多；意味著有更多的樂趣，因為你無須每個夜晚編碼工作到11點；也就意味著可以舒心的度過假期。
想要寫好單元測試，學會重構是很重要的。這里補充幾點：
1、編寫測試代碼建立基本的防護網；
2、在單元測試和功能測試之間要有取舍，如果單元測試實施成本很高，可以先加功能測試；
3、通過增加中間層來打破依賴，不是為了去掉依賴，而是為了后續的修改以及測試的便利；
4、將第一步中編寫的功能測試換成單元測試。
TDD最大的好處之一是，你可以重構程序獲得更好的設計或者只需改變某個項目的名稱……只要這種設計沒有破壞測試，前提是你有100%的信心保證你的改變沒有破壞任何東西。
TDD為遺留代碼創建單元測試，這將出現重構。從長遠的來說，這將有有助于改善你的代碼基礎知識，了解其優缺點以及代碼中現有的的硬編碼業務模塊，為你提供一個良好的開端，為提高產品質量向前邁進。