用樁解決單元測試中的內部輸入


         我前面的文章有介紹過,樁有三個功能:隔離、補齊,控制。其中,控制功能就是用於解決內部輸入的,因此,打樁並手工修改樁代碼,是解決內部輸入的方法之一。

         關於編寫樁的方法,已在第4章介紹過,這里不再重復。關於如何讓樁與用例匹配,請閱讀第9章。

遺憾的是,編寫樁代碼不但增加工作量,而且不能解決所有的內部輸入,下面對內部輸入分類分析:

         自然輸入:自然輸入調用實際代碼,不需要特別解決,跟樁無關。

          不可控:不可控調用的也是實際代碼,並不調用樁代碼,因此也不能解決。另外編寫樁代碼來代替實際代碼行不行?在應該調用實際代碼的時候,要想調用樁代碼可能很麻煩,例如,底層函數位於同一個文件,或同一個類,通常要用編譯條件來區分實際代碼和樁代碼,不但麻煩,而且污染產品代碼。

難於初始化:也是調用實際代碼。

          靜態輸入:靜態輸入只涉及到局部靜態變量,沒有調用底層函數,當然也不能用樁來代替。

         中斷輸入:中斷輸入是在不確定位置,中斷調用不確定的代碼形成的,也不能用樁來代替。

         失真:失真是打樁造成的,調用的是樁代碼。在比較簡單的情形下,可以用命名法來控制樁代碼的輸出,即給每個用例命名,樁代碼中判斷用例名來決定輸出,具體方法在前文已經介紹過。如果在同一個用例中,多次調用同一個樁,每次要求輸出不同,命名法就無效了。這種情形是很常見的,例如一個函數多次調用同一個底層函數,或在循環中調用樁代碼。一個被測函數可能調用多個樁,一個樁又可能被多個被測函數調用,這種多對多的關系下,很難維護用例與樁的對應。用例可能很多,還可能要不斷增加和修改,維護用例與樁輸出的關系也很麻煩。

  

       總之,在實際的應用中,在測試的時間成本受限的情形下,編寫樁代碼一般只能解決部分失真,難以適應復雜的應用。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com