2011-12-29 62 views
1

人們可以編寫單元測試無論是古典或mockist方式每http://martinfowler.com/articles/mocksArentStubs.html爲單一方法編寫classist和mockist單元測試是否有優勢?

會編寫,因爲兩個狀態和行爲測試的代碼的一個方法增加了健壯性既classist和mockist單元測試?

我的同事們似乎只是一直在嘲笑,並且因爲他們是「榜樣」,所以假設我會嘲笑,除非我有充分的理由不這樣做。 (我是單元測試新手)。然而,我覺得測試只是嘲弄的方式假定未經測試的私有方法的實現的正確性,這就是爲什麼我也想要classist測試(間接測試私有方法)的原因。

還是浪費時間?

+1

這聽起來像是一個概念性問題,我想知道它是否適合[Programmers.SE](http://programmers.stackexchange.com)? – Adam 2011-12-29 10:18:53

+0

由於這個問題涉及到私有方法的單元測試,你還可以檢查[你如何測試私有方法?](http://stackoverflow.com/q/250692/706456) – oleksii 2011-12-29 11:42:56

回答

1

私有方法只是一個類的內部運作。換句話說,如果你完全測試了公共方法,那麼私有方法,但是根據定義,只是做他們需要做的事情,因爲只有公共行爲很重要。

我對'狀態'有兩個想法。

1)如果狀態是內部(私有),那麼它是實現行爲如何實現的實現。這是一個內部的「祕密」。如果它很重要,那麼測試結果的行爲。

2)如果國家是公開的......沒有問題。

我會去嘲笑。

1

用Mocks測試確實間接測試私有方法 - 任何私有方法都應該在調用堆棧中使用一些公共方法。如果你已經完成了你的公共方法的100%代碼覆蓋,你所有的私有方法都會被調用。
我記得Fowler的文章,區別在於mockist測試類的內部工作 - 他們驗證你的類調用其他類API的預期。如果你不能正確使用它,你的班級的功能將會受到影響 - 例如,如果你不寫一些數據到數據庫,甚至更糟糕:寫錯了數據。

0

模擬或存根通常不用於測試私有成員,因爲這些成員是封裝的核心,並且在較新版本的程序集中,甚至不存在私有成員的存在。如果您確實需要對私人會員進行單元測試,請考慮閱讀How do you unit test private methods?

使用存根而不是模擬的一個很好的理由是顯而易見的,即當您需要在特定操作後驗證對象的狀態時,如果它適合您將使用它的任務。有人誤認爲嘲笑是一種新的一代單元測試和一個不應該使用過時的存根。事實上,您可以單獨或組合使用兩種技術。

0

是的。使用這兩種策略可以確保測試代碼的健壯性,因爲您正在測試代碼之間的依賴關係(模擬器)和模擬生產環境(狀態)的功能之間的代碼合同。通過混合這兩種方法,您可以保證測試方法的平衡。

但是請注意,基於狀態的測試通常需要更多的開銷,因爲您必須爲所有與測試對象有關的組件設置和配置環境。這通常會導致脆弱的測試。將一小部分基於狀態的測試用於模擬測試就足夠了。

使用嘲笑策略促進了單一職責原則,每個職責都有一套有限的職責,並依賴其他職責來履行職責。根據我的經驗,如果對象之間的責任定義不清晰,您會發現自己陷入基於狀態的測試,這表明封裝或抽象問題。

0
Will writing both classist and mockist unit tests for a single method increase robustness of the code since both state and behaviour is tested? 

否兩次測試是複製。

我上次檢查時,這些方法並不是獨佔性的,而是它們是互補的。根據個別測試的具體情況,您可以選擇最佳方法。

  • 如果您正在處理類的行爲,其中依賴性是測試友好的使用基於狀態的測試。
  • 如果您正在處理對文件系統/網絡的依賴性,則無法選擇交互。我打電話給SaveFile()嗎?然而,這不是一個介於任何兩個相互呼叫的類之間的接口的免費通行證。雖然這是對「嘲弄者」方法的普遍批評,但事實是,真正的「嘲笑者」非常努力地發現最小的健壯角色/界面並指定絕對最小值(期望值)。貨物信徒定義所有聲稱它是正確的方法之間的接口;角色是不穩定的變化磁鐵,測試有太多的期望導致脆弱的測試。每次界面更改時,都會進行大量的測試維護。
相關問題