如何處理那些TDD破門人？

Question

就我個人而言，我更喜歡單元測試，並將它們寫成「良好」的覆蓋範圍。 （假設我儘可能努力編寫好的測試;）

像往常一樣，稍後有人需要在代碼中添加一些功能（將類添加到類等等）。他不打破這些書面單元測試，但拒絕寫更多（這將涵蓋他編寫的代碼的附加功能）。 這導致了tdd過程中的一個大洞（甚至可能是一個破窗戶效應）

我能做些什麼來讓他寫這些測試？ 你如何處理這些人？

Answer 1

請記住，TDD主要不是要生成良好的單元測試覆蓋率;首先要確保你寫的代碼能夠做到你期望的第二，並且提供第三個高質量測試。

當另一個程序員在沒有寫測試的情況下擴展一個類時，他們錯過了這些好處，你應該對它們感到可惜。但是當你工作時，你將繼續以最好的方式工作（首先測試），因爲你知道它可以獲得解耦的代碼，這對客戶來說很簡單，而且你的代碼可以滿足你的期望。

對於你來說最大的痛苦是你必須小心你重構的內容：如果你正在重構正在測試的代碼，那麼你可以走得更快，設計將會快速和安全地改進。如果你正在重構未經測試的代碼，那麼你應該對重構它非常謹慎（可能只使用可靠的自動工具來完成）或者添加測試。

最終，您將繼續從使用TDD中受益，因爲您在TDD受損同事受到影響時能夠更快速地生成更清晰，更正確的代碼。

Answer 2

除了公司政策和他們經理的影響，你可以做的事情不多。也許在您的源代碼管理工具中有一些方法要求公開任何公開的單元測試被標記爲這樣。

你甚至可以編寫一個宏，它是構建過程的一部分，用於查找標記爲PUBLIC（我是VB人）的任何東西，然後檢查以確保在解決方案的某個地方有代碼的單元測試充分鏈接它的評論。如果沒有相關的單元測試，會破壞構建，並向整個開發組發送電子郵件，這使得非測試人員感到羞愧。

也許我會設置在這裏，現在我想想...

Answer 3

如果你有一個構建過程中，你可以使用像NCover或PartCover工具和構建失敗如果覆蓋ISN」足夠。

Answer 4

使用某些工具跟蹤代碼覆蓋範圍，例如對於Java，有Emma，併爲每個版本生成一個管理報告。當數字太低或下降時，管理層應調查原因。

Answer 5

配對編程。有兩個人在做某些事情時，程序員不太可能採取這樣的快捷方式。

Answer 6

播放「別惹我兄弟！」的視頻夥計作爲警告

Answer 7

不要將此作爲對抗！你問的是如何強迫同事做某件事，他明顯沒有看到任何好處。你不能讓某人使用TDD--就像你已經見過的那樣。開發人員接受TDD的唯一方式是當別人幫助他們達到這個「aha！」時時刻。尊重彼此的同事，並通過自己的行爲向他/她展示，並積極幫助他/她克服心理障礙。

Answer 8

教你的同事怎麼辦TDD，使他們能夠把他們的大腦倒（我有這樣的感覺，當我試圖TDD第一次），並開始先寫測試。

一旦我做了我的一個朋友的程序員，誰也不知道TDD實驗。我來到他家，我們開始使用TDD編寫Tetris（我們當天花了大約6個小時，並且進展得很好）。首先我寫了一個測試方法，然後他編寫了代碼來通過測試。起初，他有點反對寫「最簡單的事情，可能可行」（如在第一次簡單的測試中對返回值進行硬編碼），並且沒有提前計劃，但是無論如何他吸了起來並遵循了我的指示。隨着我們的進步，慢慢地，他開始明白這一切的重點。

Answer 9

以身作則。你的同事可能根本不知道如何適當地使用TDD。下次發生時，爲他們寫一個單元測試。確保指出這一點對他們說：「嘿，我注意到你加入X功能的程序沒有單元測試，所以我寫了一個給你，並把它放在這裏。」這樣他們就有了一個例子，並且不會因爲不得不詢問如何進行單元測試而感到尷尬。

只有做到這一次或兩次。之後，請務必提及將來的事件。你會在差異禮貌「嘿，你沒有寫的功能單元測試Ÿ，它會真正幫助我，如果你願意寫一個我」會讓驚訝。記住，你的目標不是嘗試讓他們編寫測試。這是爲了使寫作測試不會比不寫測試更麻煩。

如果以上不工作，它的時間與管理的討論。你已經嘗試着友好地解決這個問題，所以現在是時候考慮一​​種不太友好的方法。