我編寫了一個簡單的單元測試，它反映了我對應用整體結構的理解：
public void testResourceBreakdown(){
Resource resource=createResource();
List requests=createRequests();
assignRequestToResource(resource, requests);
List tickets=createTickets();
assignTicketToResource(resource, tickets);
Map result=new ResourceBreakdownService().search(resource);
verifyResult(result,resource,requests,tickets);
}
請注意verifyResult()方法。首先，我通過遞歸地打印返回結果的內容來了解它的結構。verifyResult()方法使用這一結構去驗證返回值是否包含有正確的數據：
private void verifyResult(Map result, Resource rsc, List<Request> requests, List<Ticket> tickets){
assertTrue(result.containsKey(rsc.getId()));
// in this simple test case, actual workload is empty
UtilizationBean emptyActualLoad=createDummyWorkload();
List resourceWorkLoad=result.get(rsc.getId());
UtilizationBean scheduleWorkload=calculateWorkload(rsc,requests);
assertEquals(emptyActualLoad,resourceWorkLoad.get(0));
assertEquals(scheduleWorkload,resourceWorkLoad.get(1));
Map requestDetailWorkload = (Map)resourceWorkLoad.get(3);
for (Request request : requests) {
assertTrue(requestDetailWorkload.containsKey(request.getId());
UtilizationBean scheduleWorkload0=calculateWorkload(rsc,request);
assertEquals(emptyActualLoad,requestDetailWorkload.get(request.getId()).get(0));
assertEquals(scheduleWorkload0,requestDetailWorkload.get(request.getId()).get(1));
}
// omit code to check tickets
}
繞開障礙
上述單元測試開起來簡單，但實際上復雜。首先，ResourceBreakdownService.search()方法與運行時環境緊密綁定，它需要訪問數據庫，其它服務，鬼知道還需要些什么。像許多遺留系統一樣，該資源管理系統沒有任何單元測試基礎架構。為了訪問運行時服務，只能開啟整個系統，這不僅昂貴，而也不方便。
啟動系統服務器端的類是ServerMain。該類也像一塊化石，通過它你能看到程序的演進過程。該系統是10年前寫成的，那時還沒有Spring和Hibernate，只有JBoss和Tomcat的早期版本。在那時，勇敢的先行者們不得不新手動手做很多事情，所以他們創建了自用的集群，緩存服務，以及連接池。后來，他們以某種方式加入了JBoss和Tomcat(但不幸地是，他們留下了自己創建的服務，所以程序遺有了兩套事務管理機制和三種連接池。)
我決定將ServerMain復制到TestServerMain中，當調用TestServerMain.main()時卻失敗了：
org.springframework.beans.factory.BeanInitializationException: Could not load properties; nested exception is
java.io.FileNotFoundException: class path resource [database.properties] cannot be opened because it does not exist
at
org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:78)
是的，很容易就能搞定！我弄來一個database.properties屬性文件，并把它置入測試類路徑中，再次啟動測試程序。這次則拋出一個異常：
java.io.FileNotFoundException: .\server.conf (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at java.io.FileReader.<init>(FileReader.java:41)
at com.foo.bar.config.ServerConfigAgent.parseFile(ServerConfigAgent.java:1593)
at com.foo.bar.config.ServerConfigAgent.parseConfigFile(ServerConfigAgent.java:1720)
at com.foo.bar.config.ServerConfigAgent.parseConfigFile(ServerConfigAgent.java:1712)
at com.foo.bar.config.ServerConfigAgent.readServerConf(ServerConfigAgent.java:1581)
at com.foo.bar.ServerConfigFactory.initServerConfig(ServerConfigFactory.java:38)
at com.foo.bar.util.HibernateUtil.setupDatabaseProperties(HibernateUtil.java:207)
at com.foo.bar.util.HibernateUtil.doStart(HibernateUtil.java:135)
at com.foo.bar.util.HibernateUtil.<clinit>(HibernateUtil.java:125)
server.conf是存在于某處，但這種方法讓我很不爽。只不過是寫個單元測試，就馬上暴露出了程序中的問題。HibernateUtil，顧名思義，應該只關注由database.properties文件提供的數據庫信息。那為什么它還需要訪問server.conf文件呢？該文件是用來配置服務器端參數的。有一線索可用來判斷代碼是否有異味：如果你感覺你是在讀一部偵探小說，并不停在問"為什么"，那么這段代碼通常就不好。我已經花了大量時間去閱讀ServerConfigFactory，HibernateUtil和ServerConfigAgent中的代碼，并且還嘗試著去弄清楚HibernateUtil是如何使用database.properties，但在這個問題上，使我急切地想得到一個運行的服務器。除了這種方法以外，還有一種解決途徑，這個武器就是AspectJ。
void around():
call(public static void com.foo.bar.ServerConfigFactory.initServerConfig()){
System.out.println("bypassing com.foo.bar.ServerConfigFactory.initServerConfig");
}
對不懂AspectJ的伙計們來說，上面那段話的意思是：當運行到對ServerConfigFactory.initServerConfig()的調用時，AspectJ會打印一條信息，然后直接返回，而不再進入該方法本身。感覺這就像是駭客入侵，但這非常高效。遺留系統中滿是謎團與問題。在任一給定的時刻，每個人都需要作出他具有戰略性的一擊。當時，依據用戶滿意度，我做的最值得稱道的事情就是修復了資源管理系統中的缺陷，并改進了它的性能。矯正其它方面的問題并不是我需要關注的。但是，我會把它記在頭里，之后我會轉回來解決ServerMain中的亂麻。
在HibernateUtil從server.conf中讀取必要信息這個調用點，我指示它從database.properties中讀取這些信息：
String around():call(public String com.foo.bar.config.ServerConfig.getJDBCUrl()){
// code omitted, reading from database.properties
}
String around():call(public String com.foo.bar.config.ServerConfig.getDBUser()){
// code omitted, reading from database.properties
}
你可能已經猜到剩下的工作了：解決運行時障礙，使它做起來更方便或更自然些。但如果已經現成的Mock對象，那就復用它。例如，TestServerMain.main()會在如下位置失敗：
- Factory name: java:comp/env/hibernate/SessionFactory
- JNDI InitialContext properties:{}
- Could not bind factory to JNDI
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet
parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
這是因為沒有啟動JBoss的命名服務。我可以使用相同的AspectJ技術去解決這個問題，但InitialContext是一個很大的Java接口，它包含有許多方法，我不想去實現每個方法--那實在太繁冗了。隨便查了一下，發現Spring已經提供一個Mock類SimpleNamingContext，所以就在測試用例使用這個類：
SimpleNamingContextBuilder builder = new SimpleNamingContextBuilder();
builder.bind(“java:comp/env/hibernate/SessionFactory”,sessionFactory);
builder.activate();
經過幾輪嘗試后，我已能成功執行TestServerMain.main()方法了。與ServerMain相比，它要簡單多了，它模擬了許多JBoss服務，并且它沒有糾結于集群管理。
創建構建模塊
TestServerMain連接到一個真實的數據庫。遺留系統會將意想不到的邏輯隱藏于存儲過程中，更糟糕地是，甚至會隱藏于觸發器中。基于相同的整體結構考慮，我認為當時試圖去理解隱藏于數據庫中的神秘邏輯并去模擬這樣的一個數據庫是不明智的，所以我決定讓測試用例去訪問真實的數據庫。
需要重復地執行測試用例，以確保我對產品做的每一點兒改變都能夠通過測試。在每次執行時，測試程序將在數據庫中創建資源與請求。不同于單元測試的傳統套路，有時候你并不想在每個用例執行完成之后銷毀由該用例創建的數據，以使運行環境變得干凈。到目前為止，測試與重構實踐是一種實情調查的探索方式--通過嘗試著進行測試去學習遺留系統。你可能想檢查由測試用例在數據庫中創建的數據，或者為了確定每一項功能都能如期運行，你可能還想在運行時系統中使用這些數據。這就意味著，測試用例必須在數據庫中創建獨一無二的數據實例，以避免與其它用例沖突。應該有一些工具類去方便地創建這些數據實例。
此處有一個簡單的創建資源的構建模塊：
public static ResourceBuilder newResource (String userName) {
ResourceBuilder rb = new ResourceBuilder();
rb.userName = userName + UnitTestThreadContext.getUniqueSuffix();
return rb; }
public ResourceBuilder assignRole(String roleName) {
this.roleName = roleName + UnitTestThreadContext.getUniqueSuffix();
return this;
}
public Resource create() {
ResourceDAO resourceDAO = new ResourceDAO(UnitTestThreadContext.getSession());
Resource rs;
if (StringUtils.isNotBlank(userName)) {
rs = resourceDAO.createResource(this.userName);
} else {
throw new RuntimeException("must have a user name to create a resource");
}
if (StringUtils.isNotBlank(roleName)) {
Role role = RoleBuilder.newRole(roleName).create();
rs.addRole(role);
}
return rs;
}
public static void delete(Resource rs, boolean cascadeToRole) {
Session session = UnitTestThreadContext.getSession();
ResourceDAO resourceDAO = new ResourceDAO(session);
resourceDAO.delete(rs);
if (cascadeToRole) {
RoleDAO roleDAO = new RoleDAO(session);
List roles = rs.getRoles();
for (Object role : roles) {
roleDAO.delete((Role)role);
}
}
}
ResourceBuilder是Builder與Factory模式的實現；你得悠著點兒去用它：
ResourceBuilder.newResource(“Tom”).assignRole(“Developer”).create();
該類也包含一個戰場清掃方法：delete()。在早期的重構實踐中，我沒有經常調用這個方法，因為我經常啟動該系統，然后引入測試用例中的數據，并檢驗柱狀圖是否正確。
此處非常有用的一個類就是UnitTestThreadContext，它按照線程的不同去存儲Hibernate會話，并為每個你想創建的數據實體的名稱的后面加上一個唯一的字符串，因此保證了實體的唯一性。
public class UnitTestThreadContext {
private static ThreadLocal<Session> threadSession=new ThreadLocal<Session>();
private static ThreadLocal<String> threadUniqueId=new ThreadLocal<String>();
private final static SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd HH_mm_ss_S");
public static Session getSession(){>
Session session = threadSession.get();
if (session==null) {
throw new RuntimeException("Hibernate Session not set!");
}
return session;
}
public static void setSession(Session session) {
threadSession.set(session);
}
public static String getUniqueSuffix() {
String uniqueId = threadUniqueId.get();
if (uniqueId==null){
uniqueId = "-"+dateFormat.format(new Date());
threadUniqueId.set(uniqueId);
}
return uniqueId;
}
…
}
集中起來看
現在我可以啟動這個最低限度的基礎框架了，并能運行簡單的測試用例：
protected void setUp() throws Exception {
TestServerMain.run(); //setup a minimum running infrastructure
}
public void testResourceBreakdown(){
Resource resource=createResource(); //use ResourceBuilder to build unique resources
List requests=createRequests(); //use RequestBuilder to build unique requests
assignRequestToResource(resource, requests);
List tickets=createTickets(); //use TicketBuilder to build unique tickets
assignTicketToResource(resource, tickets);
Map result=new ResourceBreakdownService().search(resource);
verifyResult(result);
}
protected void tearDown() throws Exception {
// use TicketBuilder.delete() to delete tickets
// use RequestBuilder.delete() to delete requests
// use ResourceBuilder.delete() to delete resources
使用該方法，我繼續編寫更復雜的測試用例，重構產品程序與測試程序。
靠著這些測試用例的武裝，我對"上帝類"ResourceBreakdownService一點點兒地進行分解。我不會透露更多的細節，這會使你難以理解；有許多書都可以教你如何安全地進行重構。
糟糕的Map_Of_Array_Of_Map_Of…數據結構現在被組裝成ResourceLoadBucket，該類使用了Composite模式。它包含有特定級別的評估工效與實際工效，下一級別的工效可通過aggregate()方法聚合而成。最終程序要清潔的多，性能也更優。它甚至暴露了一些隱藏于原有代碼復雜邏輯中的缺陷。當然，我也根據這種方法改進了單元測試。
貫穿于這次重構實踐，我始終堅持的關鍵原則就是大局觀思想。我挑選著工作方向并持續堅持著大局觀原則，繞開當前并不重要的任務，然后構建一個最低限度的測試基礎架構，我的團隊則會繼續使用這個基礎架構去重構系統的其它部分。仍然在測試基礎架構中保留了一些駭客侵入式的AspectJ程序，因為在業務上沒有必要去清除它們。我不僅重構了一個非常復雜的功能領域，而且還對遺留系統進行了深入的認知。對待一個遺留應用，就如同對待一件易碎的瓷器，它不會給你帶來任何安全感。深入其中，并對其進行重構，如此，遺留應用才可能在未來得以幸存。