如何激勵同事編寫單元測試?

　　從管理人員到開發者，每個人都在說單元測試，但是卻很少有人執行。有關單元測試的好處相信大家也能例舉出一二，但很多時候，開發者面對自己的項目代碼卻無從下手。

　　Lurkerbelow在公司里是唯一執行單元測試的一名開發者，他深知單元測試帶來的好處，也積極提倡單元測試。他甚至與公司的管理層人員、開發者都討論過單元測試，但卻無人對此感興趣。 為了與開發人員形成一條戰線，Lurkerbelow甚至“被迫“提交了代碼審查( Gerrit)和持續集成開發( Jenkins)。

　　無奈之下，Lurkerbelow在 Stack Exchange發出上“求救”，拋出《如何激勵同事進行單元測試?》的話題，引發了眾多開發者的關注，紛紛獻策。

　　對此， CSDN研發頻道從中摘譯了幾個較為重要的觀點與大家分享，希望能引起大家的共鳴。

　　實質的文檔或許有幫助

　　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為遺留代碼創建單元測試，這將出現重構。從長遠的來說，這將有有助于改善你的代碼基礎知識，了解其優缺點以及代碼中現有的的硬編碼業務模塊，為你提供一個良好的開端，為提高產品質量向前邁進。

　　更多精彩回答點擊查看： Programmers.stackexchange

　　英文出自： Arstechnica

　　什么是單元測試(Unit Testing)?

　　在計算機編程中，單元測試(又稱為模塊測試)是針對程序模塊(軟件設計的最小單位)來進行正確性檢驗的測試工作。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數、過程等;對于面向對象編程，最小單元就是方法，包括基類(超類)、抽象類、或者派生類(子類)中的方法。

　　為什么要做單元測試?

　　單元測試的目的，是將應用程序的所有源代碼，隔離成最小的可測試的單元，保證每個單元的正確性。理想情況下，如果每個單元都能保證正確，就能保證應用程序整體相當程度的正確性。

　　另一方面，單元測試也是一種特殊類型的文檔，相對于書面的文檔，測試腳本本身往往就是對被測試代碼的實際的使用代碼，對于幫助開發人員理解被測試單元的使用是相當有幫助。

原文轉自：http://www.csdn.net/article/2013-03-18/2814535-unit-tests