單元測試之關鍵問題解答

2021-08-22 07:59:42 字數 1313 閱讀 8157

近來特別關注單元測試的應用。大家可能會笑了,單元測試都n年前提出的了,您老怎麼現在才來做呢。是的,單元測試幾乎人人都在提,但是真正做好的沒幾個。

我們幾個同事在討論這個的時候,發現這裡面有很多因素。相信大家也在實踐過程中都遇到過。

這是最經常被提到的問題。往往有三個答案:

針對**測試,往往也被稱為針對類進行測試。

針對模組介面進行測試。這種模組往往是沒有介面性質的。

針對業務功能進行測試。類似於模擬需求測試。

在回答這個問題之前,我們都回顧一下,《測試驅動開發》中,強調的是story的概念。story就是乙個應用場景。用程式的語言的來翻譯的話,就是將需求例項化。

但是kent beck顯然沒有將這個概念明確化。這樣難怪,業務模型,是基於不同層次來說的。如果你只是設計乙個類,那麼這個類本身也是有需求的。那麼這個類的需求和整個軟體的需求是不是一致對待呢?

個人傾向於第三類的測試,一二為補充。

不過這裡重點說一下業務功能的測試難點,那就是模態窗體的測試。這個難點的罪魁禍首是windows的訊息機制決定的。每乙個模態窗體都有自己的訊息迴圈(死迴圈)在處理訊息,當從乙個模態窗體切換到另乙個模態窗體的時候,測試**就不能繼續下去。

針對這個問題,我的處理方式,就是「解鈴還須繫鈴人」。通過windows的訊息迴圈就可以穿透這種切換的休克。當然了,處理方式還是比較複雜的。

這往往是單元測試不能繼續的藉口。應該說,很多人還是熱衷於進行單元測試的。可是你在後期詢問單元測試的作用的時候,他們就會非常遺憾地告訴你,由於需求變更太頻繁,單元測試**已經不能工作了。

幾乎所有的程式設計師都能明白,前期的質量,會節省後期的進度。但是好像老闆不知道。至少,很多程式設計師都相信這點。

不管怎麼說,單元測試**真的就這麼放棄了嗎?其實很簡單,在你的考核體系中,加上單元測試**失敗的懲罰。因為選擇乙個技術,只是乙個決策問題。而保障乙個技術,那就是管理問題了。

不過,要注意的是,永遠忘記單元測試必須時刻進行執行。每一次**簽入的時候,必須執行一次。必須認識到,有了這個自動機制,才能保障你的單元測試持續工作下去。

非常多的人都認為,乙個系統如果不針對單元測試進行設計,那麼其可測試性就會降低,以至於不可以繼續下去。

我並不懷疑設計的必要性,但這個說法最讓我不得不懷疑另乙個看上去毫不相干的觀點:嘗試和執行單元測試,需要的是勇氣和決心。

這點其實kent beck在xp開發方式的介紹中,就說明了這個問題。作為執行的主體,人的性格很可能影響最終執行結果。

軟體工程中有很多新的工具,但我們往往發現叫好不叫座,而原因往往也是使用中國的一句古話就是:具體問題具體分析。但是回過頭來分析一下,其實很多具體問題都是可以有辦法解決的。將這些總結貢獻出來,希望我們中國的軟體技術走得更快點。

單元測試之關鍵問題解答

近來特別關注單元測試的應用。大家可能會笑了,單元測試都n年前提出的了,您老怎麼現在才來做呢。是的,單元測試幾乎人人都在提,但是真正做好的沒幾個。我們幾個同事在討論這個的時候,發現這裡面有很多因素。相信大家也在實踐過程中都遇到過。這是最經常被提到的問題。往往有三個答案 針對 測試,往往也被稱為針對類進...

單元測試之Django單元測試

每個應用,自帶tests.py 整合在django的專案檔案裡,更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...

kafka關鍵問題解釋

1 kafka如何處理消費過的訊息 1 如果想消費已經被消費過的資料 consumer是底層採用的是乙個阻塞佇列,只要一有producer生產資料,那consumer就會將資料消費。當然這裡會產生乙個很嚴重的問題,如果你重啟一消費者程式,那你連一條資料都抓不到,但是log檔案中明明可以看到所有資料都...