雖然以前用easymock測(cè)試過(guò)Dao，但那些Dao的實(shí)現(xiàn)，要么就hibernate，要么就用spring，而這兩個(gè)框架的執(zhí)行正確與否我們是不用關(guān)心的。JDBC是不是也這樣測(cè)試了。答案是肯定的。
????? 這幾天要用存儲(chǔ)過(guò)程跟jdbc來(lái)做個(gè)項(xiàng)目，想想也有好長(zhǎng)一段時(shí)間沒(méi)用過(guò)JDBC來(lái)做項(xiàng)目了。該復(fù)習(xí)復(fù)習(xí)了。
????? 前陣子學(xué)了easymock，真好現(xiàn)在可以派上用場(chǎng)了。不過(guò)在測(cè)試的過(guò)程中還是遇到了不小問(wèn)題，想來(lái)是自己基礎(chǔ)不好的緣故。
?????? 這次不TDD了，太麻煩了。
?????? 先看看我們要測(cè)試的代碼
?????
java 代碼
?
- CallableStatementcstmt?=?null;??
- ????????try?{??
- ????????????cstmt?=?_conn.prepareCall("{call?LUCK_LOAD_COMMON(?,?)}");??
- ????????????cstmt.setString(1,?"1");??
- ????????????cstmt.registerOutParameter(2,?java.sql.Types.VARCHAR);??
- ??
- ????????????cstmt.executeUpdate();??
- ????????????return?cstmt.getString(2);??
- ??
- ????????}?catch?(Exception?e)?{??
- ????????????GxDebug.logException(e);??
- ????????????e.printStackTrace();??
- ????????????return?null;??
- ????????}?finally?{??
- ????????????if?(cstmt?!=?null)??
- ????????????????try?{??
- ????????????????????cstmt.close();??
- ????????????????}?catch?(Exception?e)?{??
- ????????????}??
- ????????}??
? 代碼還挺長(zhǎng)的。從上面的代碼我們知道我們必須mock兩個(gè)對(duì)象進(jìn)去。一個(gè)是Connection， 一個(gè)是
CallableStatementcstmt 。
好再看看我們的測(cè)試代碼
java 代碼
- conn.prepareCall("{call?LUCK_LOAD_COMMON(?,?)}");??
- ????conControl.setReturnValue(cstmt);??
- ????conControl.replay();??
- ??????
- ????cstmt.setString(1,?"1");??
- ????cstmt.registerOutParameter(2,?java.sql.Types.VARCHAR);??
- ????cstmt.executeUpdate();??
- ????cstmtControl.setReturnValue(1);??
- ????cstmt.getString(2);??
- ????cstmtControl.setReturnValue("5,4,3");??
- ????cstmt.close();??
- ????cstmtControl.replay();??
- ??????
- ??????
- ????String?rusult?=?dao.getNumber();??
- ????Assert.assertEquals("5,4,3",?rusult);??
- ??????
- ????conControl.verify();??
- ????cstmtControl.verify();??
oh，my got！測(cè)試代碼比實(shí)現(xiàn)代碼還要多。這段代碼能執(zhí)行嗎？
我想可以的。easymock的原理是記錄－回放的模式。
我想要做的工作是：
1，記錄你mock對(duì)象的工作記錄，比如上面的代碼我們mock對(duì)象的工作記錄是:
java 代碼
- conn.prepareCall("{call?LUCK_LOAD_COMMON(?,?)}");??
- ????????conControl.setReturnValue(cstmt);??
- ????????cstmt.setString(1,?"1");??
- ????????cstmt.registerOutParameter(2,?java.sql.Types.VARCHAR);??
- ????????cstmt.executeUpdate();??
- ????????cstmtControl.setReturnValue(1);??
- ????????cstmt.getString(2);??
- ????????cstmtControl.setReturnValue("5,4,3");??
- ????????cstmt.close();??
- ??
?如果你工作記錄的代碼要求有返回值的話，那么你必須提供一個(gè)自定義的值給它，否則會(huì)報(bào)錯(cuò)。比如上面的
?cstmt.getString(2);??????????cstmtControl.setReturnValue("5,4,3");?? //自己定義的返回值，用作以后的比較。
上面的是記錄操作，回放的時(shí)候，easymock會(huì)把記錄的操作跟你實(shí)際的代碼進(jìn)行比較，如果里面出了什么差錯(cuò)，那么不好意思你的代碼有問(wèn)題，請(qǐng)修正后再測(cè)試。
如果有興趣可以自己試下。比如如果您
conn.prepareCall("{call LUCK_LOAD_COMMON(?,?)}");
修改為
conn.prepareCall("{call LUCK_LOAD_COMMON(?,?，？)}");
則出現(xiàn)的異常是：
junit.framework.AssertionFailedError:
Unexpected method call prepareCall("{call LUCK_LOAD_COMMON(?,?)}"):
prepareCall("{call LUCK_LOAD_COMMON(?,?)}"): expected: 0, actual: 1
prepareCall("{call LUCK_LOAD_COMMON(?,?,?)}"): expected: 1, actual: 0
現(xiàn)在我總算是對(duì)ribbon說(shuō)對(duì)于數(shù)據(jù)庫(kù)的測(cè)試還是真實(shí)環(huán)境的好。
因?yàn)槟銣y(cè)試的時(shí)候你不知道存儲(chǔ)過(guò)程是否正確。
而且如果用真實(shí)的數(shù)據(jù)庫(kù)測(cè)試，相對(duì)與mock測(cè)試，則簡(jiǎn)潔很多。而且清晰很多。
上面只是在比較少邏輯的時(shí)候測(cè)試，如果代碼邏輯復(fù)雜，我覺(jué)得寫(xiě)出來(lái)的測(cè)試代碼會(huì)更復(fù)雜，這有引出，可能維護(hù)測(cè)試代碼的工作比維護(hù)代碼的工作更累 |