1. 為什么數(shù)據(jù)庫(kù)腳本也要寫(xiě)單元測(cè)試聊聊DolphinDB開(kāi)發(fā)的真實(shí)痛點(diǎn)先說(shuō)一個(gè)我自己的經(jīng)歷。前兩年在做一套基于DolphinDB的量化因子計(jì)算平臺(tái)核心邏輯全寫(xiě)在存儲(chǔ)函數(shù)里。當(dāng)時(shí)大家約定俗成的做法是寫(xiě)完函數(shù)直接跑一遍歷史數(shù)據(jù)看看結(jié)果大概對(duì)就行。結(jié)果有一次修改了一個(gè)公共因子函數(shù)加了兩個(gè)參數(shù)進(jìn)去改完當(dāng)天所有策略的結(jié)果曲線(xiàn)都正常但到了第二周做歸因分析時(shí)才發(fā)現(xiàn)因子權(quán)重在某個(gè)邊界場(chǎng)景下算錯(cuò)了——原因很簡(jiǎn)單參數(shù)默認(rèn)值在重構(gòu)時(shí)悄悄變了而所有下游調(diào)用都用了默認(rèn)參數(shù)等于整個(gè)平臺(tái)跑在一套錯(cuò)誤的計(jì)算邏輯上。那次事故之后我開(kāi)始認(rèn)真研究DolphinDB的單元測(cè)試方案。和Java、Python生態(tài)里JUnit、pytest這種開(kāi)箱即用的測(cè)試框架不同DolphinDB作為一個(gè)時(shí)序數(shù)據(jù)庫(kù)加計(jì)算引擎官方雖然提供了test相關(guān)的函數(shù)和方法但整個(gè)社區(qū)的實(shí)踐案例非常少文檔也比較零散。更麻煩的是數(shù)據(jù)庫(kù)腳本測(cè)試有個(gè)天然的心理門(mén)檻大多數(shù)人覺(jué)得SQL寫(xiě)對(duì)了就是對(duì)了沒(méi)必要再套一層測(cè)試代碼。但恰恰是這種心態(tài)讓數(shù)據(jù)計(jì)算邏輯里的隱性Bug成了最大的風(fēng)險(xiǎn)源。這篇文章不會(huì)去復(fù)述官方文檔里那點(diǎn)函數(shù)簽名而是把我實(shí)際搭建一套DolphinDB單元測(cè)試體系的過(guò)程完整寫(xiě)出來(lái)。從最基礎(chǔ)的斷言怎么寫(xiě)到怎么組織測(cè)試文件、怎么集成到CI流程再到那些不踩一次坑根本不會(huì)注意到的細(xì)節(jié)。無(wú)論你是剛接觸DolphinDB還是已經(jīng)在生產(chǎn)環(huán)境跑了好幾個(gè)項(xiàng)目這篇文章應(yīng)該都能給你一些可以直接抄走的思路。和普通編程語(yǔ)言的單元測(cè)試相比DolphinDB的測(cè)試有幾個(gè)完全不同的問(wèn)題要處理。第一DolphinDB腳本通常強(qiáng)依賴(lài)數(shù)據(jù)庫(kù)環(huán)境很多函數(shù)直接讀寫(xiě)表對(duì)象不像Java可以隨便mock一個(gè)對(duì)象第二時(shí)序數(shù)據(jù)天然有順序和時(shí)間的敏感性測(cè)試數(shù)據(jù)構(gòu)造比普通業(yè)務(wù)數(shù)據(jù)復(fù)雜第三DolphinDB腳本是解釋執(zhí)行運(yùn)行時(shí)的錯(cuò)誤信息往往不如編譯型語(yǔ)言直觀定位問(wèn)題需要額外的手段。這些痛點(diǎn)不解決測(cè)試寫(xiě)得再多也只是自欺欺人。下面我就按自己搭建這套測(cè)試體系的實(shí)際順序一層層講清楚。2. 測(cè)試前的關(guān)鍵設(shè)計(jì)測(cè)試庫(kù)與測(cè)試數(shù)據(jù)的隔離策略2.1 為什么必須用獨(dú)立的測(cè)試庫(kù)而不是直接連生產(chǎn)庫(kù)這個(gè)問(wèn)題聽(tīng)起來(lái)像廢話(huà)但實(shí)際項(xiàng)目里真有人圖省事直接連開(kāi)發(fā)庫(kù)跑測(cè)試。我自己第一次寫(xiě)DolphinDB測(cè)試時(shí)也干過(guò)這種事測(cè)試用例里直接讀取線(xiàn)上正在用的因子表點(diǎn)運(yùn)行看著結(jié)果通過(guò)就覺(jué)得萬(wàn)事大吉。這么做的后果是災(zāi)難性的。第一測(cè)試結(jié)果受數(shù)據(jù)變化影響同樣的用例今天跑過(guò)明天可能就掛了但你根本分不清是代碼邏輯變了還是底層數(shù)據(jù)變了第二測(cè)試用例里如果涉及寫(xiě)入、更新、刪除操作會(huì)對(duì)開(kāi)發(fā)庫(kù)的真實(shí)數(shù)據(jù)造成污染一旦測(cè)試邏輯有Bug誤刪數(shù)據(jù)連恢復(fù)都很麻煩第三如果你跑的是性能測(cè)試高頻讀寫(xiě)還會(huì)拖慢其他同事的查詢(xún)。正確做法是在DolphinDB里單獨(dú)建一個(gè)測(cè)試庫(kù)。我常用的建庫(kù)邏輯是這樣// 測(cè)試庫(kù)路徑dfs://test_unit login(admin, 123456) if (!existsDatabase(dfs://test_unit)) { db database(dfs://test_unit, VALUE, 2020.01.01..2023.12.31) }注意這里的分區(qū)方式。對(duì)于測(cè)試庫(kù)來(lái)說(shuō)時(shí)間分區(qū)不一定是最優(yōu)選完全取決于你測(cè)試的代碼邏輯。如果是針對(duì)某個(gè)特定業(yè)務(wù)場(chǎng)景的測(cè)試建議按照業(yè)務(wù)ID做HASH分區(qū)這樣構(gòu)造數(shù)據(jù)時(shí)更靈活如果測(cè)試的代碼本身就涉及時(shí)間序列處理那就用時(shí)間分區(qū)但分區(qū)粒度要小一點(diǎn)避免每次測(cè)試都要跨全部分區(qū)掃描。我自己的經(jīng)驗(yàn)是測(cè)試庫(kù)盡量只用一張主表所有測(cè)試用例都往這張表里灌數(shù)據(jù)。好處是字段結(jié)構(gòu)統(tǒng)一構(gòu)造測(cè)試數(shù)據(jù)的helper函數(shù)不用反復(fù)重寫(xiě)壞處是不同用例之間可能互相干擾。這個(gè)問(wèn)題后面講用例隔離時(shí)再細(xì)說(shuō)。2.2 測(cè)試數(shù)據(jù)的構(gòu)造方法手工寫(xiě)死 vs 腳本生成構(gòu)造測(cè)試數(shù)據(jù)是整個(gè)DolphinDB單元測(cè)試?yán)镒钊菀妆坏凸赖囊徊?。很多人在測(cè)試庫(kù)建完后就直接手寫(xiě)數(shù)據(jù)data table( 1..10 as id, rand(100.0, 10) as val, take(buy, 10) as side )這種寫(xiě)法在Demo里沒(méi)問(wèn)題但真實(shí)項(xiàng)目里幾類(lèi)數(shù)據(jù)是不能靠rand的邊界值比如極小的數(shù)、極大的數(shù)、空值、NULL、NaN時(shí)間類(lèi)數(shù)據(jù)跨月、跨年、閏年、時(shí)區(qū)邊界、時(shí)間戳精度邊界字符串類(lèi)數(shù)據(jù)空字符串、超長(zhǎng)字符串、特殊字符、中文編碼正確的做法是把測(cè)試數(shù)據(jù)構(gòu)造封裝成helper函數(shù)按場(chǎng)景批量生成。舉個(gè)例子如果你要測(cè)試一個(gè)因子計(jì)算的函數(shù)它的輸入是某只股票過(guò)去N天的分鐘K線(xiàn)那么你的數(shù)據(jù)構(gòu)造函數(shù)大概長(zhǎng)這樣def prepareKLineData(code, startDate, endDate, barCount) { // 基于日期區(qū)間生成分鐘級(jí)時(shí)間戳 ts interval(2023.01.04 09:30:00.000, 2023.01.04 15:00:00.000, 1000) // 再搭配隨機(jī)價(jià)格、成交量等字段 ... }這樣的好處是測(cè)試用例里只需要指定股票代碼和時(shí)間范圍就能得到一套可預(yù)期的、穩(wěn)定的輸入數(shù)據(jù)不用每個(gè)用例都寫(xiě)一大段table(...)。2.3 測(cè)試用例之間的數(shù)據(jù)隔離事務(wù)和表級(jí)清理DolphinDB腳本執(zhí)行時(shí)如果沒(méi)有顯式開(kāi)啟事務(wù)一條語(yǔ)句的失敗可能會(huì)導(dǎo)致部分寫(xiě)入生效。這就引出一個(gè)非常惡心的現(xiàn)實(shí)問(wèn)題測(cè)試A往主表里插了10條數(shù)據(jù)測(cè)試B跑的時(shí)候發(fā)現(xiàn)數(shù)據(jù)多了10條結(jié)果不對(duì)。我的解決思路是分層處理。簡(jiǎn)單場(chǎng)景下每個(gè)測(cè)試用例跑完后強(qiáng)制清理自己寫(xiě)入的數(shù)據(jù)def cleanupData(code) { t loadTable(dfs://test_unit, mainTable) t.delete!(sql(, t, code code )) }復(fù)雜場(chǎng)景下直接把表drop掉重建。雖然慢一點(diǎn)但絕對(duì)干凈而且測(cè)試用例之間徹底互不影響。考慮到DolphinDB的建表速度其實(shí)不慢我后來(lái)更多采用這種做法。提示對(duì)于涉及分布式表的測(cè)試data的可見(jiàn)性還受DolphinDB事務(wù)提交時(shí)機(jī)的影響。如果你在存儲(chǔ)過(guò)程里寫(xiě)數(shù)據(jù)但不主動(dòng)commit測(cè)試?yán)镒x到的可能是舊快照。遇到這種詭異問(wèn)題時(shí)先確認(rèn)數(shù)據(jù)和讀取是否在同一個(gè)會(huì)話(huà)里。3. DolphinDB單元測(cè)試的函數(shù)選型assert家族與自定義斷言3.1 官方assert函數(shù)的用法和局限性DolphinDB內(nèi)置的斷言函數(shù)主要有assert、eqObj、eqFloat這幾個(gè)。它們的用法很簡(jiǎn)單assert condition, error message如果condition為false會(huì)拋出異常并打印error message。eqObj用來(lái)比較兩個(gè)對(duì)象是否相等eqFloat用來(lái)比較浮點(diǎn)數(shù)。但直接用這些函數(shù)寫(xiě)測(cè)試有兩個(gè)尷尬的地方。第一錯(cuò)誤信息不夠友好。比如eqObj比較兩個(gè)表內(nèi)容時(shí)它只會(huì)告訴你兩個(gè)對(duì)象不相等不會(huì)告訴你具體是哪一行哪一列不一樣第二斷言失敗時(shí)缺少上下文信息你看到一個(gè)錯(cuò)誤堆棧時(shí)根本不知道是哪個(gè)測(cè)試用例掛的。所以我在實(shí)際項(xiàng)目中會(huì)對(duì)這些內(nèi)置函數(shù)再做一層包裝。包裝后的斷言函數(shù)至少要達(dá)到三個(gè)標(biāo)準(zhǔn)失敗時(shí)能輸出用例名稱(chēng)和預(yù)期值/實(shí)際值對(duì)表對(duì)象的比較能定位到具體行列對(duì)浮點(diǎn)數(shù)的比較支持自定義精度3.2 自定義斷言讓測(cè)試失敗信息不再像天書(shū)下面是我實(shí)際在用的一個(gè)簡(jiǎn)化版斷言包裝函數(shù)def assertEq(expected, actual, msg) { if (expected ! actual) { errorMsg msg \n Expected: expected.str() \n Actual: actual.str() throw error(errorMsg) } true }別小看這個(gè)簡(jiǎn)單的包裝它解決了一個(gè)非常實(shí)際的問(wèn)題——報(bào)錯(cuò)信息可讀性。DolphinDB的原生assert拋出異常時(shí)如果表達(dá)式比較長(zhǎng)錯(cuò)誤信息會(huì)顯示一堆語(yǔ)法上下文真正的邏輯差異反而被淹沒(méi)。包裝之后一眼就能定位問(wèn)題。對(duì)于浮點(diǎn)數(shù)比較我再加一個(gè)精度參數(shù)def assertEqFloat(expected, actual, epsilon 0.0001, msg Float mismatch) { if (abs(expected - actual) epsilon) { errorMsg msg \n Expected: expected.str() \n Actual: actual.str() \n Diff: (abs(expected - actual)).str() throw error(errorMsg) } true }這里要特別說(shuō)明一下為什么浮點(diǎn)數(shù)比較需要epsilon。DolphinDB的浮點(diǎn)數(shù)計(jì)算和其他語(yǔ)言一樣存在精度損失問(wèn)題。你算一個(gè)理論值可能是0.333333但實(shí)際計(jì)算結(jié)果是0.3333329999如果直接用比較測(cè)試必掛。設(shè)一個(gè)合理的epsilon是所有數(shù)值計(jì)算類(lèi)測(cè)試的共識(shí)具體閾值取決于你的業(yè)務(wù)精度要求。做量化因子計(jì)算時(shí)我一般取1e-6做偏底層的高精度統(tǒng)計(jì)時(shí)可能需要更小。3.3 表對(duì)象的深度比較逐行逐列定位差異DolphinDB里最常見(jiàn)的測(cè)試對(duì)象是表。兩個(gè)表是否相等在不同語(yǔ)義下判斷標(biāo)準(zhǔn)完全不同——字段順序要不要管行順序重不重要時(shí)間精度算不算差異這些都需要在斷言里明確。我封裝的表比較函數(shù)核心邏輯如下def assertTableEqual(expectedTb, actualTb, msg, sortByCol ) { // 1. 檢查行數(shù)列數(shù)是否一致 if (expectedTb.rows() ! actualTb.rows()) { throw error(msg : Row count mismatch. Expected expectedTb.rows().str() , got actualTb.rows().str()) } // 2. 檢查列集合是否一致 expCols expectedTb.columnNames().sort() actCols actualTb.columnNames().sort() if (expCols ! actCols) { throw error(msg : Column set mismatch.) } // 3. 如果指定了排序列先排序再逐行比較 if (sortByCol ! ) { expectedTb select * from expectedTb order by sortByCol actualTb select * from actualTb order by sortByCol } // 4. 逐行比較 for (i in 0:expectedTb.rows()) { for (c in expCols) { if (expectedTb[i][c] ! actualTb[i][c]) { throw error(msg : Row i.str() col c mismatch. Expected expectedTb[i][c].str() , got actualTb[i][c].str()) } } } true }這個(gè)函數(shù)看起來(lái)長(zhǎng)但實(shí)際用起來(lái)非常順手。尤其是第3步的排序參數(shù)在實(shí)際項(xiàng)目中幾乎是必須的——因?yàn)閿?shù)據(jù)庫(kù)查詢(xún)結(jié)果的行順序通常沒(méi)有嚴(yán)格保證兩個(gè)表內(nèi)容一致但順序不同不能算測(cè)試失敗。如果對(duì)這一點(diǎn)沒(méi)有清醒認(rèn)識(shí)你會(huì)在測(cè)試?yán)锉桓鞣N順序不一致的假失敗搞到崩潰。4. 測(cè)試用例的組織方式從單個(gè)腳本到分級(jí)測(cè)試集4.1 一個(gè)測(cè)試文件只測(cè)一個(gè)功能模塊DolphinDB的腳本文件組織比較自由可以在gui里直接運(yùn)行也可以用dolphindb控制臺(tái)加參數(shù)執(zhí)行。這種自由既是優(yōu)點(diǎn)也是缺點(diǎn)——自由過(guò)了頭測(cè)試文件就會(huì)變成一團(tuán)亂麻。我建議按模塊來(lái)分文件。比如一個(gè)完整的量化因子平臺(tái)測(cè)試目錄大概長(zhǎng)這樣tests/ common/ assertUtils.dos dataUtils.dos factor/ test_momentumFactor.dos test_volatilityFactor.dos test_liquidityFactor.dos dataProcess/ test_klineClean.dos test_adjustFactor.dos validation/ test_portfolioCalc.dos每個(gè)測(cè)試文件里針對(duì)一個(gè)功能函數(shù)寫(xiě)一組相關(guān)用例。比如test_momentumFactor.dos里測(cè)試的就是動(dòng)量因子計(jì)算函數(shù)在不同輸入下的表現(xiàn)。這樣當(dāng)某個(gè)用例失敗時(shí)你能第一時(shí)間縮小排查范圍不用在一堆亂七八糟的用例里大海撈針。4.2 測(cè)試用例命名規(guī)范和輸出效果DolphinDB沒(méi)有像JUnit那樣Test注解來(lái)標(biāo)記測(cè)試方法所以測(cè)試用例的組織要靠規(guī)范和約定。我的做法是在main函數(shù)里逐個(gè)調(diào)用測(cè)試用例函數(shù)并用print輸出每個(gè)用例的執(zhí)行狀態(tài)def test_momentum_basic() { // 基本場(chǎng)景 ... print(PASS: momentum basic case) true } def test_momentum_emptyInput() { // 空輸入場(chǎng)景 ... print(PASS: momentum empty input case) true } def main() { test_momentum_basic() test_momentum_emptyInput() // ... }運(yùn)行結(jié)果大致長(zhǎng)這樣PASS: momentum basic case PASS: momentum empty input case FAIL: momentum NaN case配合assertEq里自定義的報(bào)錯(cuò)信息測(cè)試失敗時(shí)能迅速定位到具體用例和具體斷言。4.3 如何做測(cè)試分組冒煙測(cè)試、回歸測(cè)試、全量測(cè)試測(cè)試用例數(shù)量多了之后一個(gè)很實(shí)際的問(wèn)題是每次代碼改動(dòng)都跑全量測(cè)試時(shí)間成本太高只跑冒煙測(cè)試又怕漏掉回歸問(wèn)題。我在自己的項(xiàng)目里將測(cè)試集分了三級(jí)冒煙級(jí)只跑主流程和核心邊界大概幾分鐘內(nèi)結(jié)束每次提交代碼前必跑回歸級(jí)覆蓋一個(gè)模塊內(nèi)所有關(guān)鍵函數(shù)和主要邊界條件代碼合并前跑全量級(jí)所有測(cè)試文件的所有用例發(fā)布新版本前跑實(shí)現(xiàn)方式也很樸素每個(gè)測(cè)試文件都單獨(dú)定義main()再寫(xiě)一個(gè)總?cè)肟谀_本用include引入所有測(cè)試文件然后按需執(zhí)行include tests/factor/test_momentumFactor.dos include tests/factor/test_volatilityFactor.dos // 冒煙測(cè)試只執(zhí)行特定的幾個(gè)函數(shù) test_momentum_basic() test_volatility_basic() // 回歸測(cè)試執(zhí)行文件里所有main這種手動(dòng)控制的方式雖然不如JUnit的注解靈活但在DolphinDB的生態(tài)里已經(jīng)是足夠清晰可靠的做法了。5. 從零跑通一個(gè)完整測(cè)試用例以因子計(jì)算函數(shù)為例5.1 被測(cè)函數(shù)一個(gè)簡(jiǎn)單的動(dòng)量因子計(jì)算器為了把整個(gè)流程串起來(lái)我寫(xiě)一個(gè)極簡(jiǎn)的動(dòng)量因子計(jì)算函數(shù)作為被測(cè)對(duì)象。它的邏輯很簡(jiǎn)單輸入某股票過(guò)去N天的收盤(pán)價(jià)計(jì)算當(dāng)前價(jià)格相對(duì)N天前的漲跌幅def momentumFactor(closePrices, n) { if (closePrices.size() n) { return NULL } pastPrice closePrices[n] currentPrice closePrices[closePrices.size() - 1] return (currentPrice - pastPrice) / pastPrice }這個(gè)函數(shù)雖然業(yè)務(wù)簡(jiǎn)單但非常適合演示測(cè)試要覆蓋的各種場(chǎng)景。5.2 手寫(xiě)測(cè)試用例覆蓋正常、邊界、異常三類(lèi)輸入針對(duì)這個(gè)函數(shù)我會(huì)設(shè)計(jì)如下測(cè)試用例def test_momentum_normal() { prices [10.0, 10.5, 10.8, 11.0, 11.5, 12.0] result momentumFactor(prices, 3) assertEqFloat((12.0 - 10.8) / 10.8, result, 0.0001, Normal case failed) print(PASS: momentum normal case) true } def test_momentum_nLessThanLength() { prices [10.0, 10.5, 10.8] result momentumFactor(prices, 5) assertEq(NULL, result, n larger than length should return NULL) print(PASS: momentum nlength case) true } def test_momentum_zeroDivision() { prices [0.0, 0.0, 0.0, 0.0, 1.0, 1.0] result momentumFactor(prices, 3) // 分母為0應(yīng)該返回NULL或者拋異常取決于函數(shù)定義 ... }第三個(gè)用例其實(shí)暴露了被測(cè)函數(shù)的一個(gè)設(shè)計(jì)缺陷當(dāng)過(guò)去價(jià)格是0時(shí)做除法直接得到無(wú)窮大這在量化計(jì)算里是應(yīng)該被提前攔截的。所以這個(gè)測(cè)試用例會(huì)倒逼你去修改被測(cè)函數(shù)——這就是單元測(cè)試驅(qū)動(dòng)代碼改進(jìn)的真實(shí)過(guò)程。5.3 完整測(cè)試腳本的運(yùn)行方式和結(jié)果解讀把這些用例組織到一個(gè)文件里后在DolphinDB GUI里運(yùn)行該文件或在命令行用dolphindb -script test_momentum.dos執(zhí)行。輸出大致如下PASS: momentum normal case PASS: momentum nlength case FAIL: momentum zeroDivision case Error message: Division by zero ...堆棧信息...看到Fail時(shí)第一件事不是去改測(cè)試而是先判斷是測(cè)試用例的預(yù)期設(shè)置錯(cuò)了還是被測(cè)函數(shù)確實(shí)有bug。在這個(gè)例子里顯然是被測(cè)函數(shù)該加一個(gè)空值和零值檢查。這也是單元測(cè)試黃金法則測(cè)試失敗時(shí)代碼和測(cè)試都有嫌疑不能默認(rèn)代碼是錯(cuò)的或者測(cè)試是錯(cuò)的要去看具體斷言信息來(lái)定位。6. 面向?qū)嶋H項(xiàng)目的測(cè)試框架搭建目錄、入口腳本與DolphinDB腳本執(zhí)行的CI集成6.1 一套可直接復(fù)用的測(cè)試目錄結(jié)構(gòu)和入口設(shè)計(jì)在項(xiàng)目里形成一套固定的目錄和入口約定后團(tuán)隊(duì)里每個(gè)人寫(xiě)測(cè)試時(shí)不需要思考放哪怎么跑而是直接照模板寫(xiě)效率和規(guī)范性都會(huì)有明顯提升。我的標(biāo)準(zhǔn)結(jié)構(gòu)如下projectRoot/ code/ # DolphinDB腳本主目錄 factors/ momentum.dos volatility.dos dataProcess/ klineClean.dos tests/ # 測(cè)試腳本目錄 common/ assertUtils.dos dataUtils.dos factors/ test_momentum.dos test_volatility.dos runAllTests.dos # 總?cè)肟谀_本在runAllTests.dos中按依賴(lài)順序引入測(cè)試文件最后統(tǒng)一執(zhí)行。這里有個(gè)在DolphinDB中容易踩的坑include的路徑問(wèn)題。如果你的測(cè)試腳本使用了相對(duì)路徑那么執(zhí)行時(shí)的工作目錄不同include會(huì)失敗。穩(wěn)妥的做法是把測(cè)試根目錄設(shè)為一個(gè)全局變量所有include基于這個(gè)變量拼接testRoot /home/user/project/tests/ include testRoot common/assertUtils.dos include testRoot factors/test_momentum.dos // ...6.2 如何嵌入CI流程命令行運(yùn)行DolphinDB腳本CI集成這塊DolphinDB其實(shí)比很多數(shù)據(jù)庫(kù)產(chǎn)品要方便因?yàn)樗峁┟钚袌?zhí)行方式dolphindb -home ./server -script ./tests/runAllTests.dos -localExec 1在Jenkins或GitLab CI里可以直接把這個(gè)命令包裝成一個(gè)構(gòu)建步驟。關(guān)鍵是怎么判斷測(cè)試通過(guò)還是失敗。DolphinDB腳本執(zhí)行時(shí)如果腳本拋出未捕獲的異常進(jìn)程會(huì)以非零狀態(tài)碼退出。所以我們的runAllTests.dos必須保證只要有一個(gè)測(cè)試用例失敗就一定拋異常不能吞掉錯(cuò)誤。我在runAllTests.dos末尾會(huì)加一個(gè)總判斷allPassed true // 執(zhí)行用例時(shí)把結(jié)果累加到allPassed if (!allPassed) { throw error(Unit test suite FAILED) } print(Unit test suite PASSED)這樣CI腳本才能拿到正確的退出碼。6.3 我對(duì)官方測(cè)試工具的補(bǔ)充日志輸出和并行執(zhí)行思路DolphinDB的test模塊里也提供了類(lèi)似測(cè)試框架的函數(shù)可以自動(dòng)發(fā)現(xiàn)測(cè)試用例并執(zhí)行但我在生產(chǎn)項(xiàng)目里用得不多主要是它在錯(cuò)誤信息展示、批量執(zhí)行順序控制上還不夠靈活。除非只是寫(xiě)幾個(gè)最基礎(chǔ)的冒煙腳本否則我都會(huì)用自建框架。日志輸出上我會(huì)把每次測(cè)試運(yùn)行的輸出同時(shí)寫(xiě)到CSV文件里方便和上次運(yùn)行做diff。命令很簡(jiǎn)單output exec result from resultsTable saveText(output, /data/test_logs/run_ now().format(yyyyMMdd_HHmmss) .csv)并行執(zhí)行方面DolphinDB支持submitJob來(lái)并行跑任務(wù)。但單元測(cè)試的場(chǎng)景我不建議一開(kāi)始就并行——先有序跑通等到用例量實(shí)在太多、單次執(zhí)行時(shí)間過(guò)長(zhǎng)時(shí)再考慮把互相獨(dú)立的測(cè)試文件拆到不同的worker里執(zhí)行。7. 踩坑實(shí)錄我在DolphinDB單元測(cè)試中遇到過(guò)的四個(gè)典型問(wèn)題7.1 事務(wù)可見(jiàn)性存儲(chǔ)過(guò)程里寫(xiě)的數(shù)據(jù)外面讀不到有一次我在測(cè)試一個(gè)K線(xiàn)清洗函數(shù)函數(shù)內(nèi)部會(huì)對(duì)分布式表做update操作。測(cè)試?yán)镎{(diào)用完函數(shù)后立即去讀表結(jié)果讀出來(lái)的還是舊數(shù)據(jù)。排查了大半天最后發(fā)現(xiàn)是DolphinDB的事務(wù)模型問(wèn)題——寫(xiě)入未提交時(shí)其他會(huì)話(huà)或后續(xù)查詢(xún)看不到變化。解決方案有兩種一種是在被測(cè)函數(shù)內(nèi)部顯式commit或endTransaction另一種是在測(cè)試用例里等待事務(wù)提交完成后再讀。對(duì)于單元測(cè)試來(lái)說(shuō)我推薦后者因?yàn)榍罢邥?huì)改變被測(cè)函數(shù)的生產(chǎn)行為風(fēng)險(xiǎn)太大。7.2 NULL值和空表的斷言陷阱DolphinDB的空表、NULL值和空字符串在不同API和上下文中的表現(xiàn)非常不一致。比如從一個(gè)沒(méi)有數(shù)據(jù)的表里select count(*)結(jié)果可能是0但如果你select * from tbl limit 10再用rows()取行數(shù)可能返回的又是一個(gè)特殊的空對(duì)象。這些細(xì)節(jié)你寫(xiě)測(cè)試時(shí)幾乎必踩。我的建議是對(duì)NULL和空表的比較不要直接拿返回值做而是用isNull()、size()這類(lèi)顯式函數(shù)來(lái)判斷避免各種隱式轉(zhuǎn)換的坑。7.3 分布式表的局部數(shù)據(jù)一致性DolphinDB的分布式表是按分區(qū)存儲(chǔ)的如果測(cè)試數(shù)據(jù)橫跨多個(gè)分區(qū)讀取時(shí)的順序可能和你插入時(shí)的順序不一致。前面提到的assertTableEqual之所以要加sort參數(shù)主要就是為了應(yīng)對(duì)這個(gè)問(wèn)題。另外如果你在測(cè)試?yán)飫h除了分布式表的某些記錄要注意刪除操作可能存在異步性緊接著的查詢(xún)不一定立刻反映結(jié)果。7.4 include順序的循環(huán)依賴(lài)問(wèn)題當(dāng)測(cè)試腳本依賴(lài)多個(gè)工具文件時(shí)很容易出現(xiàn)A include BB include CC又反向include A的情況。DolphinDB對(duì)循環(huán)include的報(bào)錯(cuò)提示比較隱晦有時(shí)表現(xiàn)為找不到函數(shù)而不是循環(huán)依賴(lài)。實(shí)踐中我會(huì)把工具函數(shù)斷言、數(shù)據(jù)構(gòu)造嚴(yán)格和測(cè)試用例文件分離工具文件之間互不依賴(lài)從根上避免這個(gè)問(wèn)題。8. 把單元測(cè)試變成團(tuán)隊(duì)習(xí)慣一些切實(shí)可行的管理建議技術(shù)方案講完最后聊一點(diǎn)軟性的東西。單元測(cè)試這件事難點(diǎn)從來(lái)不在寫(xiě)代碼而在讓整個(gè)團(tuán)隊(duì)持續(xù)地、規(guī)范地執(zhí)行。我的經(jīng)驗(yàn)是三個(gè)必須第一測(cè)試必須和業(yè)務(wù)代碼同時(shí)提交。如果約定提交業(yè)務(wù)代碼時(shí)可以不帶測(cè)試那測(cè)試的覆蓋率只會(huì)越來(lái)越低。我在團(tuán)隊(duì)的PR模板里直接加了一欄本次變更的測(cè)試用例沒(méi)填就cherry-pick提交被打回。強(qiáng)制兩三次后大家就習(xí)慣了。第二CI里跑測(cè)試結(jié)果必須實(shí)時(shí)反饋。測(cè)試失敗的信息要直接發(fā)到群里否則就算CI里掛了也沒(méi)人會(huì)去看。反饋鏈路越長(zhǎng)修復(fù)的成本越高。第三測(cè)試用例的維護(hù)必須納入日常迭代。業(yè)務(wù)邏輯變了被測(cè)函數(shù)的預(yù)期結(jié)果也會(huì)變這時(shí)候測(cè)試代碼不是要?jiǎng)h掉而是要同步更新。如果團(tuán)隊(duì)里出現(xiàn)為了讓測(cè)試通過(guò)而改測(cè)試的風(fēng)氣必須立刻糾正——這種情況通常意味著測(cè)試本身就失去了價(jià)值。根據(jù)我個(gè)人這段時(shí)間在DolphinDB上推廣單元測(cè)試的體會(huì)最大的收益反而不是抓住多少Bug而是讓整個(gè)團(tuán)隊(duì)養(yǎng)成了寫(xiě)代碼前先想清楚輸入輸出的習(xí)慣。當(dāng)你習(xí)慣性地為每個(gè)函數(shù)搭配幾個(gè)邊界用例時(shí)很多設(shè)計(jì)上的含糊之處在開(kāi)發(fā)階段就暴露了根本不需要等到測(cè)試階段。如果你所在的項(xiàng)目也正在用DolphinDB做復(fù)雜的計(jì)算邏輯我強(qiáng)烈建議你別嫌麻煩盡早把這套東西搭起來(lái)。數(shù)據(jù)腳本的錯(cuò)誤往往不是報(bào)錯(cuò)而是算得不對(duì)而單元測(cè)試是唯一能在不看盤(pán)、不看策略結(jié)果的情況下幫你判斷算得對(duì)不對(duì)的可靠手段。