在上一個博客中 ，我談到了如何處理行為不佳的不可測試的 （1） SitePropertiesManager 類，以及如何通過提取接口來創建存根。 但是，如果由于舊類的源代碼已被鎖定在第三方JAR文件中而無法訪問它，會發生什么情況？ 答案是您真正沒有想到的事情之一，但是當您看到它時，您會意識到它是顯而易見的。

為了證明這一點，我將重寫上一個博客中的代碼 ? （2）測試我的簡單AddressService 。 情況相同， AddressService必須加載站點屬性并決定是否返回地址：

public Address findAddress(int id) {logger.info("In Address Service with id: " + id);Address address = Address.INVALID_ADDRESS;if (isAddressServiceEnabled()) {address = addressDao.findAddress(id);address = businessMethod(address);}logger.info("Leaving Address Service with id: " + id);return address;}private boolean isAddressServiceEnabled() {return new Boolean(propManager.findProperty("address.enabled"));}

…除了，我要假裝SitePropertiesManager被鎖定在JAR文件中。

我之前提出的有關使遺留代碼更具可測試性的所有觀點仍然存在：您需要使用SpringFactoryBean實現轉向依賴注入，并停止依賴靜態工廠方法getInstance （）。 您還需要一種創建存根的方法，該存根允許您將代碼與我們的流氓類愉快使用的數據庫和文件系統隔離開 SitePropertiesManager 。 在這種情況下，由于該類被鎖定在一個JAR文件中，因此您不能簡單地提取一個接口，您必須更加狡猾并使用繼承。 使用繼承編寫存根是很簡單的，并且只需要幾行代碼，如下所示：

public class StubSitePropertiesUsingInheritance extends SitePropertiesManager {private final Map<String, String> propMap = new HashMap<String, String>();public void setProperty(String key, String value) {propMap.put(key, value);}@Overridepublic String findProperty(String propertyName) {return propMap.get(propertyName);}
}

這里的主要思想是，現在我可以將存根實例多態注入到我的AddressService類中，而無需知道它已經被愚弄了。

public class LegacyAddressServiceUsingInheritanceTest {private StubAddressDao addressDao;private StubSitePropertiesUsingInheritance stubProperties;private LegacyAddressService instance;@Beforepublic void setUp() {instance = new LegacyAddressService();stubProperties = new StubSitePropertiesUsingInheritance();instance.setPropertiesManager(stubProperties);}@Testpublic void testAddressSiteProperties_AddressServiceDisabled() {/* Set up the AddressDAO Stubb for this test */Address address = new Address(1, "15 My Street", "My Town", "POSTCODE", "My Country");addressDao = new StubAddressDao(address);instance.setAddressDao(addressDao);stubProperties.setProperty("address.enabled", "false");Address expected = Address.INVALID_ADDRESS;Address result = instance.findAddress(1);assertEquals(expected, result);}@Testpublic void testAddressSiteProperties_AddressServiceEnabled() {/* Set up the AddressDAO Stubb for this test */Address address = new Address(1, "15 My Street", "My Town", "POSTCODE", "My Country");addressDao = new StubAddressDao(address);instance.setAddressDao(addressDao);stubProperties.setProperty("address.enabled", "true");Address result = instance.findAddress(1);assertEquals(address, result);}
}

您可能會問：為什么不總是使用繼承，答案是該技術的缺點是測試代碼與野生的SitePropertiesManager類緊密耦合。 在這種情況下，這并不是什么大問題，而且作為一個務實的程序員，我想這并不重要，因為擁有整潔，經過測試和可靠的代碼要比擁有松散耦合的代碼更好，但沒有單元測試。

---

^（1）設計時未考慮單元測試。
^（2）源代碼可從GitHub獲得：

git：//github.com/roghughe/captaindebug.git

參考： Captain Debug's Blog上的JCG合作伙伴 Roger Hughes提供了更多有關為遺留代碼創建存根的測試技術7 的信息 。

相關文章 ：

• 測試技巧–不編寫測試
• 端到端測試的濫用–測試技術2
• 您應該對什么進行單元測試？ –測試技術3
• 常規單元測試和存根–測??試技術4
• 使用模擬的單元測試–測試技術5
• 為舊版代碼創建存根–測試技術6
• 為什么要編寫單元測試–測試技巧8
• 一些定義–測試技術9