嗨！我最近嘗試在C#中開發一個小型項目，在整個項目中，我們的團隊使用測試驅動開發（TDD）技術（xunit, moq）。C++＆正確的TDD
我真的覺得這很棒，因爲（當與C#配對時）這種方法允許在編碼時放鬆，在重構時放鬆和放鬆。我懷疑所有這些東西實際上簡化了編碼過程，並且它允許（最終，對我來說）以較少的腦細胞工作獲得相同的結果。
之後當我嘗試使用TDD搭配C++（我用Google Test和Google Mock庫），而且，我也不知道爲什麼，但我倒認爲TDD這裏是退後一步，在快速應用開發方面。
我有些時候不得不花費大量時間思考我的測試，建立適當的嘲笑，重建它們並在我的顯示器上發誓。
而且，我顯然不能問「我做錯了什麼？或者「我的方法出了什麼問題？」，因爲我不知道要描述什麼。但是，如果有人已經習慣TDD在C++（也可能是C#），你能否告訴我如何正確地做到這一點。
框架建議，架構方法，普通的編碼建議 - 如果您有TDD & C++的經驗，請回復。
我認爲TDD在C++中比C＃更難做。缺乏反思以及與靜態多態性相比，常見（並且常常充分證明）不情願依賴動態多態性（接口和遺漏）確實使得難以剔除許多類。
C++有一些非常聰明的單元測試框架，但對他們來說太聰明的事情主要是他們試圖繞過語言限制。
TDD在動態語言中效果最佳。這是一個使用Python工作的好方法。它在C＃中是可行的（它不是動態的，但具有全面的反射功能）
在C++中，它通常是有問題的。這並不意味着它不能或不應該完成，但是當你這樣做的時候，期望不得不對它做更多的努力。有時候，你可能會更好地使用另一種方法。
嘗試最簡單 - CxxTest。
無論平臺如何，TDD都需要一些練習才能獲得正確的結果。有些人似乎沒有意識到，你試圖解決的問題的性質可能會對你如何輕鬆地將TDD應用於解決方案產生重大影響。過去我遇到了一些問題，我知道我想要走的解決方案，但要弄清楚如何以似乎符合TDD模型的方式解決問題非常困難。現在有幾個原因可能會發生，而且不可能說出處理這種情況的「正確」方法。
在這一點上，我遇到這種問題的第一反應是重新檢查我對這個問題的原始假設。我是否比它所需要的更復雜？我是否試圖編寫測試來達成我已經決定的設計，而不是讓測試指導設計？這只是一個時髦的問題，我需要接受典型的TDD方法在這種情況下不起作用嗎？
對於這一個有趣的討論，你可以看看this blog post從Bob大叔馬丁，他談到由羅恩傑弗里斯企圖create a Sudoku Solver using TDD，它並沒有真正的工作。現在因爲這種嘗試沒有產生好的解決方案並不意味着TDD沒有用處，而只是意味着解決的問題更加複雜，並不適用於TDD的緊急設計方法。
我覺得測試驅動開發很難做到正確，有時測試只是流動，有時需要一些跳躍。爲了保持速度，我經常離開TDD方法。這對我來說不是問題，因爲我爲所有已完成的代碼維護了一套完整的單元測試（允許在編碼新比特和重構時放鬆）。
你能描述一下你用於C＃的設置和C++＆gmoc＆gtest的設置之間最惱人的區別是什麼？我在C++中使用了gdock + gtest for TDD，但是我看不到這個工具有任何缺陷，但是我沒有在C＃中使用xunit + moq（地獄，我沒有用C＃編寫這麼多），所以我可能不知道我錯過了什麼。 – chalup 2010-05-25 15:47:04
嗯，我認爲'jalf'實際上寫了我的意見。我不能用比他更好的語言來解釋這些，但是當你用C＃編寫代碼並編寫所有界面的東西等等時，它看起來很「天生」。當你試圖在C++中做同樣的事情時，它開始看起來像你試圖強迫自己使用一些非常古怪的東西。也許這只是關於經驗，並習慣以正確的方式思考。 – 2010-05-25 19:55:44