前些天看見有朋友的msn簽名檔寫著「unit testing」，就問了一下他們的單元測試是怎麼做的。看來他們沒有真正做起來，只是小範圍的試一試。
一方面，他們沒有cruise control之類的工具，甚至連daily build都不見得有，單元測試也不上傳到版本控制裡。這樣做測試的意義就不大了。
另一方面，他好像把單元測試和接收測試（acceptance testing)、整合測試（integration testing）搞混淆了。因為他說，業務邏輯很複雜，測試資料不好做……
單元測試，顧名思義，就是對乙個單元的測試（好像什麼也沒說）。通常這個單元是指（類的成員）函式，或者函式的乙個功能。
每個測試就只針對一點，不涉及其餘，還是比較好寫的。函式的輸入是什麼，（物件當時的狀態是什麼），得到的輸出是什麼；有幾種不同的情況……
我感覺，同乙個函式的單元測試加在一起，就相當於這個函式的詳細設計文件。自然，設計文件應該在實現之前寫，而不是實現了以後再補。
和傳統開發方法裡的詳細設計不同，寫乙個單元測試，就寫一段**讓它通過。這樣你就不需要在實現的時候，再去讀文件，再去回憶當時是怎麼想的，能提高效率；更重要的是，這個「文件」是能反覆執行的，可以保證和實現的一致性。
如果你的開發環境配置的好，照我的經驗，寫單元測試再寫**，和直接寫**相比，不會多花什麼時間。
單元測試工具
編碼過程中有相當一部分時間是花在想清楚下一步要做什麼上，想到了就把它寫成乙個測試。這麼做是要花一點點時間，不過能幫你盡快驗證下面的實現跟你現在想的一致；能幫你理清思路，到底有幾種情況需要考慮，就寫幾個測試；能讓函式的功能更明確，只有功能明確，才能明確的測試；能讓你的介面更合理，因為不合理的話，依賴關係太多或者介面太複雜，測試寫起來會很麻煩……
最重要的是，以後你改了什麼東西，破壞了現在的介面，可以馬上知道。不會在發版本的最後一天，才有人告訴你：「這個功能以前是好的，我們已經好幾天沒有重新測試了。現在壞了，不知道問題在**。全體加班吧！」 。
繼續：
springboot做單元測試
使用intellij idea 2018.2.5 x64版本idea建立spring boot專案會直接建立好乙個test測試樣例 runwith springrunner.class springboottest test public void contextloads 但是如果沒有其他配置，僅...
學習做單元測試
開始接觸單元測試，查資料，寫例子，折騰了幾天以為可以了，針對一些輸入異常，以及資料邊界都考慮到了。可是讓高手一講解，完全不是那麼回事，還差好遠呢，下面是總結的提綱 單元測試邊界點彙總配置,資源 xml html，js 等檔案，測試場景 缺少檔案，缺少節點，節點或檔案內容錯誤 外設 外部程式集 出現的...
軟體測試之單元測試
對於一般的大型程式，我們一般都會先進行單元測試，乙個單元一般是乙個子程式 乙個類 乙個函式 乙個模組等等，根據具體情況劃分。單元測試將注意力放在各個小的單元上，使得測試人員能夠相對容易的定位到錯誤的地方，同時由於把程式進行了模組化，所以可以多個單元模組同時測試。單元測試過程主要需要考慮兩個大點 設計...