以前沒寫過，最近專案要求寫，我的疑問是：
1.比如我的輸入是A，經過演算法S()函式。我的輸出是B.問題：我的實際輸出是B，我的期望輸出C也是根據演算法S()函式.那么實際輸出B和期望輸出C一直是一樣的。我怎么測驗呢
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
這個需要很多測驗用例，因為部分正確的代碼其實也是錯誤的代碼。uj5u.com熱心網友回復：
條件覆寫，你以為正經測驗很輕松么。他的構造條件進行覆寫測驗，也的根據用例和場景進行反用例，反場景的對抗測驗
uj5u.com熱心網友回復：
寫測驗 說白了就是寫斷言那么你會下的斷言是
斷言條件a輸出A
斷言條件b輸出B
斷言a，b都木有輸出不支持
uj5u.com熱心網友回復：
d單元測驗屬于白盒測驗，做到6級覆寫就行了。uj5u.com熱心網友回復：
沒看懂你說的，，，我知道單元測驗就是斷言。但是就是我的問題實際的輸出B與我期望的輸出C，都是通過S()函式算出來的。那這個要不要測驗呢？或者說怎么該這個測驗方法，才不會出現這種情況uj5u.com熱心網友回復：
能不能詳細說一下，或者貼個鏈接uj5u.com熱心網友回復：
“寫”一個功能之前，先花時間想想如何寫測驗，而且在測驗用例中盡量多寫一些你能想到的斷言。然后運行測驗“先出錯、再改錯”。不要一上來就寫功能代碼。好的技術經理可能經常去洗掉代碼。注意是洗掉代碼。只要運行測驗而沒有出錯，說明編程干了無用功，沒有人驗收這種代碼，那么代碼其實就可以考慮洗掉了。所以技術到了一定高感度，是洗掉不必要的代碼，而不是堆砌好多代碼拿出來炫耀。
uj5u.com熱心網友回復：
“那這個要不要測驗呢？”這類問題，你的所謂“測驗”是跟在撰寫完代碼的屁股后邊，這其實是畫蛇添足，你不感覺“痛苦、多余”嗎？這種測驗代碼往往是糊弄不懂測驗驅動開發的主管的。真正的開發，是不知道寫成什么樣子。先寫測驗，而且寫“吐了”為止，再去讓測驗能夠通過。每天每一個人有空就運行幾百次測驗，每一個修改都要運行測驗幾十遍才能提交到源代碼管理系統。
如果你先寫程式，對于架構師和較大系統開發人員來說，這就好像一個特種部隊沒有任何計劃就行動，是送死的小白。
uj5u.com熱心網友回復：
測驗其實也簡單也復雜。就好像讓一幫工人砌墻，工頭會去拉一根線來作為準繩（基線）保證當前這一層磚砌整齊了。測驗也是一樣，每一個小時都有測驗，不然就別開發。uj5u.com熱心網友回復：
事實上，我是半路出家，對于大公司的流程是不了解的。
我的理解還是這樣的啊。
比如：我先寫測驗。我想到的也是輸入a,經過某種演算法輸出B，期望值C實際上在演算法寫的程序中的輸出。比如這個測驗時這樣的。那我在寫程式時也是直接拿這個演算法或者函式去用。個人感覺時一樣的
順便提一下。各位大佬有什么好的文章可以貼個鏈接過來，我去看看
uj5u.com熱心網友回復：
單元測驗A Basic Introduction To C# Unit Test For Beginners
uj5u.com熱心網友回復：
正是因為個人感覺的問題，所以才是一個工程問題。一般人都是感覺到對自己是否有利，而感覺不到對工程、對未來是否有利。所以不是靠感覺，真理一開始總是站在少數人一邊，一旦大家都自以為掌握了真理，那么真理可能也就發臭了。測驗就是要求一個程式員提高水平，從初學者變為設計師。
uj5u.com熱心網友回復：
不要僅僅滿足于就事論事去“知道一些概念”。要懂得“如何做”獲得動手實踐效率結果，而不僅僅是人人都會動口說的“是什么”，這就需要自己揣摩實踐痛點。當你腦筋還沒有轉過來的時候，可能滿腦子還只是停留在學校課堂上互相抄作業的階段，自己需要創造和設計的專案太少，那么多寫寫作業計劃、多對“自己完完整整做的專案”復盤，就知道以后如何做了。uj5u.com熱心網友回復：
最后說一句吧。實際上我每句話幾乎都在回答測驗“到底是為了什么”的問題，但是這個即是軟體工程問題是人性的問題，需要破除人性上的欺騙，才能看見工程。
uj5u.com熱心網友回復：
寫了這么多年代碼，還沒體驗過測驗驅動開發。感覺這應該是好東西，但一個是自己耐不下心來寫單元測驗，我覺得代碼寫好了，跑個幾遍也就過了，花費時間去寫測驗用例太啰嗦，花費時間可能太多，當然這也是因為測驗驅動做的少的時候，開始的時候效率低，方法可能也不對，也使得做單元測驗收益低，因此難以堅持。
另外，我覺得是不是一個人的開發，就不需要單元測驗。反正我覺得直接寫代碼跑跑更自由更方便，效率也不低吧。
uj5u.com熱心網友回復：
再問一個問題，大廠程式員都做單元測驗嗎？誰來說說。uj5u.com熱心網友回復：
我也想知道，大廠是不是必須單元測驗uj5u.com熱心網友回復：
我覺得是至少每個公開方法都 右鍵 -->“創建單元測驗”，每個方法可以創建多個，從不同維度進行測驗。至于意義，其中之一應該就是修改了某處之后，不需要費心去看其他地方會不會錯了，只要運行一下全部單元測驗就能判斷。
uj5u.com熱心網友回復：
這個其實是個工具的噱頭，實際開發的用處不大。測驗也未必是“單元測驗”，因為“單元”這個詞兒本身就是比較low的脫離了產品需求實作基線，脫離了日常開發任務驗收需求的說法，是個純粹空洞的計算機領域說法。
測驗驅動要按照每個程式員領的任務來撰寫，要按照測驗人員報的bug來撰寫，要按照需求分析和驗收測驗用例來撰寫，要按照技術經理的每日作業計劃來撰寫，要按照程式員給主管報的每日作業計劃來撰寫。什么叫“單元測驗”？什么叫做“對每個方法創建測驗”？這都是本末倒置的純技術說法，勞民傷財的做法，而非真的敏捷高效的測驗技術做法。
uj5u.com熱心網友回復：
一個程式員他寫了實作代碼然后寫代碼來測驗自己的實作代碼“有錯誤”，這不但是荒唐透頂的自欺欺人的做法，而且也是非常令人沮喪、感覺多余的測驗代碼。最低限度，你把測驗人員報告的每一條問題寫成測驗，把自己每日作業計劃上的每條文字寫成測驗代碼，這就是測驗！不管是不是用什么“單元測驗”工具來寫測驗代碼（其實無所謂），測驗的關鍵來源不在于“單元”而是來源于實踐需求。
uj5u.com熱心網友回復：
有點道理。確實感覺這個只能測驗一下方法有沒有錯誤，實際上有的時候也不太方便測驗。您說的那種測驗我沒有弄過，感覺挺復雜的。
uj5u.com熱心網友回復：
無所謂“復雜”或者“簡單”，不外乎就是寫幾個初始化陳述句以及斷言陳述句。實際上是視角不同，都是人為故意的。uj5u.com熱心網友回復：
他來了他來了，他帶著漫天廢話走來了
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
單元測驗是程式員對自己代碼的審核，某些場合你可以不干，但是如果要考核你，你就非干不可了。轉載請註明出處，本文鏈接：https://www.uj5u.com/net/9863.html
標籤：C#