jim yeh on 五月 14th, 2014

很多人都知道系統開發的功能測試很重要,但有時候我們省略它並不是認為某個功能不需要測試,而是不知道該功能該如果測試。有時候問題的關鍵是卡在環境整合的複雜性,例如牽涉 web 的 session 或是資料庫存取的問題,就讓人很難隔離這些複雜情況。當然理論上我們可以運用 Mock 的技術來隔離它們,然而現實上,即使運用這些技術可能你可能還是無法解決無法測試的問題。這時候,你需要的通常不會是尋求其它更強大的技術,而是需要在編程核心思維上,做一些小改變,來改善功能的可測性。

最近同人就碰到一個實例,讓我體會到以泛函編程(FP)典範增進功能的可測性。其實,以前遠在美國的 Perter Ho 就曾向包括同人在內的幾位點空間的朋友,分享過相同的觀念,而同人則是藉由最近的實例而對這樣的觀念有更深刻的體驗。

這個實例不是困難的問題,而是在向資料庫查詢時,組合 SQL 語句用到 IN 的條件式,但需要符合的集合卻超過 1000 個,因而導致系統的異常發生。這個問題要解決並不困難,只要每 500 個分批下 SQL 查詢,然後把每個 SQL 查詢到的資料加到查詢結果就可以了。這樣程式會寫成:

	int i = 0;
	do {
	    int fromIdx = i;
	    int toIdx = ((list.size() - i) > QUERY_BATCH_SIZE) ?
	    	    QUERY_BATCH_SIZE + i : list.size();

	    List<String> parts = list.subList(fromIdx, toIdx);

	    String sql = sqlExpr.replace(AID_LIST_REPLACEMENT,
	    	    getListToSql(parts));

	    Session session = (Session) getEntityManager().getDelegate();
	    @SuppressWarnings("unchecked")
	    List<Object[]> querylist = session.createSQLQuery(sql).list();
	    resultList.addAll(querylist);
	    i = toIdx;
	} while (list.size() - i > 0);

	return results;

只是上面這段 code 很難被驗證其功能是無誤的。假設以 SQL 向資料庫讀取資料沒問題,那麼讓人關心的問題就會是如何確認分批組合 SQL 語句的演算法會正確無誤,而不是有重覆或遺漏的部分。然而如果要針對它寫測試,那就必須準備有用的測試資料,而且也要面對此功能掛載在主機 context 的問題。我們的系統是採用 Seam Framework 架構,寫測試案例需要承擔一定的負擔及代價,之前沒有人嘗試過,而同人也覺得似乎不該貿然行事。

於是同人試著改變作法,我認為需要測試的並不是讀取資料的環境整合,而是能不能正確沒有重覆和遺漏地分批組合 SQL。所以我應該可以把這段演算抽離出來,並且可以對它做單獨的驗證。同人先用測試案例來表達我對它的願望:

public class PartsOfListTest {

    @Before
    public void setUp() throws Exception {
    }

    @After
    public void tearDown() throws Exception {
    }

    @Test
    public void test() {
	List<String> list =
		Arrays.asList("1", "2", "3", "4", "5", "6");
	List<List<String>> results =
		new PartsOfList<String>(3).from(list);

	assertEquals(results.get(0).get(0), "1");
	assertEquals(results.get(0).get(1), "2");
	assertEquals(results.get(0).get(2), "3");

	assertEquals(results.get(1).get(0), "4");
	assertEquals(results.get(1).get(1), "5");
	assertEquals(results.get(1).get(2), "6");

	results = new PartsOfList<String>(2).from(list);

	assertEquals(results.get(0).get(0), "1");
	assertEquals(results.get(0).get(1), "2");

	assertEquals(results.get(1).get(0), "3");
	assertEquals(results.get(1).get(1), "4");

	assertEquals(results.get(2).get(0), "5");
	assertEquals(results.get(2).get(1), "6");

    }
}

從測試案例中找到 PartsOfList<T> 的演算邏輯,用來把 List<T> 分批成 List<List<T>> 的串列。這樣我們就可以把一個很長的串列分成多個較短的串列,然後再進行分批的處理。建構 PartsOfList<T> 需要指定每個子串列的最大空間,並且利用 from() 傳入串列來分成多個子串列。

接下來讓測試案例過關,同人實作 PartsOfList<T> 的內容如下所示:

public class PartsOfList<T> {

    private int partSize;

    public PartsOfList(int size) {
	partSize = size;
    }

    public List<List<T>> from(List<T> list) {
	List<List<T>> results = new ArrayList<List<T>>();
	int i = 0;
	do {
	    int endIndex = (list.size() - i) > partSize ?
	    	    i + partSize : list.size();
	    List<T> part = list.subList(i, endIndex);
	    results.add(part);

	    i = endIndex;
	} while (i < list.size());
	return results;
    }
}

然後最前面的程式片段則會改成如下面的內容:

	List<List<String>> parts =
		new PartsOfList<String>(QUERY_BATCH_SIZE).from(list);
	for (List<String> aids : parts) {
	    String sql = sqlExpr.replace(AID_LIST_REPLACEMENT,
	    	    getListToSql(aids));

	    Session session = (Session) getEntityManager().getDelegate();
	    @SuppressWarnings("unchecked")
	    List<Object[]> querylist = session.createSQLQuery(sql).list();
	    resultList.addAll(querylist);
	}
	return resultList;

我們看到這樣程式碼更專注於它們各自的職責,而且 PartOfList 也可以重覆使用在其它適用的情況,更重要的是程式碼的驗證是可行的,連帶程式碼的可讀性、擴充性、以及彈性都得到加強。這又一次地讓人體會到泛函編程宣告式語意的簡潔有力,搭配與物件導向的思維的整合,無疑是提升系統抽象概念堪稱完美的組合。



     

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">