PDF相關測試一直都是手動進行，自動化測試介入的很少。我們專案，PDF是很重要的一塊，客戶經常需要將報表匯出到PDF。匯出的可能是表格，也可能是餅圖，條圖，線圖。表格的話，有flat grid，有tree grid。圖的話，花樣就更多了，圖例，座標軸…

最近的迭代有個story，是想要自動化測試能夠判斷表格匯出到PDF格式是否正確，看看現在專案用的iTextSharp能否實現這個需求。

iTextSharp是C#的PDF庫，人們經常用它來生成PDF，這個庫裡面有一小塊是解析PDF，這一小塊就是我需要用到的。一番探索之後發現，其實PDF沒有任何結構資訊，純粹就是畫圖一般畫出來的。我們專案的PDF，就是先獲取資料，然後根據資料節點，層級結構，生成相應的html檔案，最後從html生成PDF。PDF裡面的表格看起來是有結構的，就是一張表，實際上解析之後讀出來的資訊毫無結構可言。現有的庫最多可以一行一行把PDF裡面的文字讀出來，離我的預期還很遠。

比如我有如下兩個PDF報表：

用現有的iTextSharp讀出來結果如下：
Tree Grid
Fund Asset Class NPV VaR
Fund_A 1234 (2345)
Fixed Income 1234 (2345)
Fund_B 3456 (1234)
Equity 3456 (1234)

Flat Grid
Fund Asset Class NPV VaR
Fund_A 1234 (2345)
Fund_A Fixed Income 1234 (2345)
Fund_B 3456 (1234)
Fund_B Equity 3456 (1234)

每一行的文字，它預設用空格分隔，這樣的話我無從判斷這一行到底匯出來幾個單元格，因為單元格自己的內容就可能有空格。

一開始我認為這個應該有個string引數，使用者可以設定，然後解析PDF的時候用這個string作為分隔。google了很久都沒有找到，去stackoverflow上提問了，也沒有人回答。

還好這個工具是開源的，我在github上找到了原始碼：github iTextSharp

原來根本沒有這麼個引數，程式寫死了用空格分隔，詳見SimpleTextExtractionStrategy.cs 的line 145和LocationTextExtractionStrategy.cs的line 193

接下來，把原始碼下下來，在類SimpleTextExtractionStrategy和LocationTextExtractionStrategy裡面新增屬性欄位：string separator，賦預設值為空格符，使用者可以在新建類例項時傳入任何他想要的string來為它賦值。讀PDF內容的方法增加一個引數，就是類的separator欄位。

比如我在新建SimpleTextExtractionStrategy類例項時，傳入引數將separator設定為++，那麼最後我解析出來的PDF內容如下：

Tree Grid
Fund++Asset Class++NPV++VaR
Fund_A++1234++(2345)
Fixed Income++1234++(2345)
Fund_B++3456++(1234)
Equity++3456++(1234)

Flat Grid
Fund++Asset Class++NPV++VaR
Fund_A++1234++(2345)
Fund_A++Fixed Income++1234++(2345)
Fund_B++3456++(1234)
Fund_B++Equity++3456++(1234)

這樣一來，我就可以以++為splitter來split每一行內容，繼而判斷PDF格式是否正確。

客戶化開源工具確實能解決自己的問題，但是，後續如果該工具更新了，那麼merge起來也是蠻困難的…只能後續不用這個工具的新版本了…

後話：問題解決了，我去stackoverflow上回答了自己的提問，社群管理員看到之後，也覺得這個不應該寫死，應該expose出來，讓使用者自己設定值，他@了iTextSharp工具的作者。但是不知道作者是否會採納我的建議，並在下一次更新時涵蓋我的改動