1. 為什么 ABAP Unit 的快和穩(wěn)往往互相打架先說個(gè)我觀察了很久的現(xiàn)象很多 ABAP 開發(fā)者的日常工作流里寫單元測試這件事一直是個(gè)想起來重要、做起來嫌煩的環(huán)節(jié)。為什么嫌煩因?yàn)閺膶懲暌粋€(gè)業(yè)務(wù)方法、切換到測試類、補(bǔ)測試數(shù)據(jù)、跑測試、再回到業(yè)務(wù)代碼修 bug這一整條鏈路里全是上下文切換。你剛在業(yè)務(wù)類里理清楚一段 IF-ELSE 的邏輯切到測試類里又要重新回憶這個(gè)方法該返回什么、有哪些前置條件等測試跑掛了你還要在 Stack 和代碼之間來回跳。一套流程下來寫測試的時(shí)間往往比寫業(yè)務(wù)代碼還長人還累。這也是為什么很多 ABAP 項(xiàng)目里單元測試覆蓋率始終上不去——不是不想寫是工作流太不順。后來我換了思路把所有能自動(dòng)化生成的部分全部交給 ADTABAP Development Tools的 Quick Actions 去做再把 Test Code Highlighting 打開讓測試代碼的身份一眼就能被識(shí)別。這兩個(gè)功能單拎出來都不算新鮮但組合在一起效果其實(shí)是把寫測試從一道需要醞釀的工序變成了一道填空式的流程。你要做的不是從零開始敲測試類而是告訴 ADT我要測哪個(gè)方法然后往生成的骨架里填數(shù)據(jù)、寫斷言。這個(gè)過程一旦順起來ABAP Unit 的快和穩(wěn)才能真正共存——快指的是生成和執(zhí)行不拖泥帶水穩(wěn)指的是測試失敗后你能在最短時(shí)間內(nèi)定位到問題。這篇文章我會(huì)從這兩個(gè)功能的實(shí)際用法、背后原理、依賴版本、以及一套我自己打磨過的完整測試工作流講起。不管你是剛接觸 ADT 的 ABAP 新人還是已經(jīng)在 Eclipse 環(huán)境里寫了好幾年代碼的老手只要你的項(xiàng)目跑在 S/4HANA 或者基于 ABAP 的云環(huán)境上這套流程都能直接套用。2. ADT Quick Actions把寫測試變成填空題2.1 從選中方法到生成測試類只要一個(gè)快捷鍵Quick Actions 在 ADT 里的入口是Ctrl1也就是快速修復(fù)/建議這個(gè)動(dòng)作。大多數(shù) ABAP 開發(fā)者平時(shí)用它的場景是修語法錯(cuò)誤、插類型聲明這類小事但很多人忽略了一點(diǎn)當(dāng)你把光標(biāo)停在業(yè)務(wù)類的方法名上或者選中整個(gè)方法定義時(shí)ADT 會(huì)自動(dòng)識(shí)別當(dāng)前上下文并提供Generate ABAP Unit Test Class這個(gè)動(dòng)作。我實(shí)測下來最順的觸發(fā)方式是直接打開你要測試的業(yè)務(wù)類定位到目標(biāo)方法那一行按Ctrl1。彈出的建議列表里會(huì)有一個(gè)選項(xiàng)寫著Generate ABAP Unit Test Class?；剀囍驛DT 會(huì)讓你確認(rèn)要生成測試類的名字、保存包、還有測試類歸屬是放在本地測試類還是要走可傳輸?shù)臏y試包含在包里。確認(rèn)完一個(gè)完整的測試類骨架就出來了里面已經(jīng)包含了被測試類的引用、目標(biāo)方法對(duì)應(yīng)的測試方法空殼、甚至 import 語句也補(bǔ)齊了。整個(gè)過程從按鍵到看到骨架類基本在十秒以內(nèi)。我剛開始用的時(shí)候還犯過一個(gè)低級(jí)錯(cuò)誤直接在類的屬性視圖里右鍵選 New 再手動(dòng)建測試類。那個(gè)路徑不是不能用但需要你自己填的東西太多了尤其是測試類的FOR TESTING聲明、受測類的實(shí)例創(chuàng)建代碼這些完全可以交給 Quick Actions 自動(dòng)完成。手動(dòng)建不僅慢而且容易漏掉關(guān)鍵注解比如AUARDING或者側(cè)邊測試數(shù)據(jù)聲明。用 Quick Actions 生成等于 ADT 替你把骨架規(guī)范已經(jīng)擺好了你只需要往里面填業(yè)務(wù)相關(guān)的測試邏輯。2.2 測試類內(nèi)部的 Quick Actions補(bǔ)全方法簽名和輔助代碼生成骨架只是第一步。真正讓我覺得順滑的是后續(xù)在測試類里繼續(xù)用同樣的快捷鍵做補(bǔ)全。假設(shè)你要測的方法是calculate_discount生成的測試方法多半是空殼你需要寫一個(gè)實(shí)例調(diào)用。這時(shí)候把光標(biāo)停在測試方法的第一行按Ctrl1ADT 會(huì)識(shí)別你正在為哪個(gè)業(yè)務(wù)方法寫測試并給出一個(gè)類似Create call for calculate_discount的建議?；剀嚭驛DT 自動(dòng)補(bǔ)全受測類的靜態(tài)調(diào)用或者實(shí)例調(diào)用代碼包括方法參數(shù)、返回值接收變量。這一步省掉了我大量敲參數(shù)的精力尤其是參數(shù)多、類型復(fù)雜的方法手寫經(jīng)常眼花讓 ADT 自動(dòng)生成可以避免漏參數(shù)。另外測試類內(nèi)部還經(jīng)常會(huì)遇到需要 mock 外部依賴的情況。ADT 的 Quick Actions 在檢測到測試方法里引用了某個(gè)尚未聲明的對(duì)象時(shí)有時(shí)會(huì)彈出建議幫你生成測試替身聲明。雖然這個(gè)能力不如純 Java 生態(tài)的快速修復(fù)那么智能但在 ABAP 生態(tài)里已經(jīng)算非常省事了。我的習(xí)慣是只要測試類里出現(xiàn)光標(biāo)閃爍不知道下一步該寫什么的場景就先按Ctrl1看看有沒有現(xiàn)成的建議——十次里至少有六次能直接解決。2.3 關(guān)鍵快捷鍵和觸發(fā)條件速查我用過一段時(shí)間后整理了一張自己常用的快捷鍵觸發(fā)表方便在團(tuán)隊(duì)里推廣。注意一下Ctrl1是 Windows/Linux 下的按鍵macOS 上的 ADT 對(duì)應(yīng)的是Cmd1。操作目標(biāo)快捷鍵/操作觸發(fā)前提輸出結(jié)果生成測試類骨架光標(biāo)停在業(yè)務(wù)方法名上Ctrl1選 Generate ABAP Unit Test Class業(yè)務(wù)類已激活方法無語法錯(cuò)誤完整測試類含空測試方法生成實(shí)例調(diào)用光標(biāo)停在空測試方法體內(nèi)的第一行Ctrl1選 Create call測試方法與業(yè)務(wù)方法同名或有明確映射實(shí)例化 方法調(diào)用代碼塊快速修復(fù)測試類語法任意語法錯(cuò)誤行Ctrl1ADT 能理解語法修復(fù)方案補(bǔ)全 structured type 等聲明生成測試數(shù)據(jù)光標(biāo)停在測試方法內(nèi)Ctrl1視上下文選擇方法參數(shù)或局部變量缺少數(shù)據(jù)聲明局部變量聲明行需要注意的是Quick Actions 的機(jī)制是識(shí)別上下文。如果你的業(yè)務(wù)類當(dāng)前有語法錯(cuò)誤ADT 可能不會(huì)給出生成測試類的建議因?yàn)樗诮馕稣Z義時(shí)失敗了。所以每次用這個(gè)功能之前先把業(yè)務(wù)代碼保存并激活一遍確保類處于可解析狀態(tài)否則你會(huì)以為自己的 ADT 壞了其實(shí)只是代碼還沒就緒。3. Test Code Highlighting讓測試代碼的身份一眼可見3.1 這是個(gè)什么功能以及為什么要打開它Test Code Highlighting 是 ABAP Test 相關(guān)工具鏈中一個(gè)非常不起眼但影響巨大的配置。我最早注意到這個(gè)功能是因?yàn)橥碌臏y試類里測試方法名都是綠色的而我的還是普通白色。問了才知道這個(gè)能力是 Eclipse 的 ADT 插件在較新版本引入的主要作用是把有 ABAP Unit 語義的代碼元素用特殊顏色標(biāo)出來讓你在測試類編輯器里就能直觀判斷哪些方法是被測試框架識(shí)別的測試方法哪些只是輔助方法。打開的方式很簡單打開你的 Eclipse/ADT進(jìn)入 Window Preferences在搜索框里輸入ABAP Test找到 Test Code Highlighting 相關(guān)的設(shè)置項(xiàng)把它啟用。有些版本里你需要把某個(gè) preference 節(jié)點(diǎn)的前綴設(shè)置為Set才能啟用整套著色規(guī)則。注意這個(gè)功能不是默認(rèn)打開的至少在我的幾個(gè)項(xiàng)目環(huán)境里它默認(rèn)是關(guān)閉的必須要手動(dòng)開一次。而且這個(gè)配置是工作區(qū)級(jí)別的換了工作區(qū)或者換了電腦需要重新開啟。從版本角度來說我所在的項(xiàng)目用的 ADT 版本更新比較勤這個(gè)功能在 2021 年以后的版本里已經(jīng)比較穩(wěn)定。如果你的 ADT 插件版本太舊在 Preferences 里搜不到 Test Code Highlighting建議直接去 Eclipse Marketplace 或者 SAP 官網(wǎng)把 ADT 升級(jí)到最新版而不是繼續(xù)用老版本硬扛。3.2 著色規(guī)則到底標(biāo)出了什么打開 Test Code Highlighting 之后你在測試類里會(huì)看到三類明顯變化。第一類凡是被TEST注解標(biāo)記過的方法方法名會(huì)出現(xiàn)一種不同于普通方法的顏色。這個(gè)讓人一眼掃過去就知道哪些是真正跑用例的入口寫長測試類時(shí)可以快速定位應(yīng)該關(guān)注的核心方法。第二類測試類中涉及 mock比如mock_authorization或者mock_http_communication這類調(diào)用的部分ADT 會(huì)用另一種顏色把打樁的上下文標(biāo)記出來。我看過調(diào)試器里的色值和普通方法調(diào)用比這種顏色的飽和度更高辨識(shí)度很強(qiáng)。第三類也是最實(shí)用的一類斷言方法調(diào)用比如cl_abap_unit_assertassert_equals這些在著色開啟后會(huì)變得非常顯眼。這有什么用呢它解決了一個(gè)很刁鉆的問題當(dāng)測試方法寫得很長、斷言很多的時(shí)候你的眼睛需要花時(shí)間找真正的校驗(yàn)點(diǎn)。有了顏色區(qū)分掃一眼就能知道這個(gè)測試方法有沒有斷言、斷言在哪個(gè)位置。我自己用過一段時(shí)間后有個(gè)很直接的感受開啟高亮之后看測試代碼的方式變成了掃顏色而不是逐行讀。這在小測試類里可能感受不深一旦你開始維護(hù)一個(gè)包含 30 多個(gè)測試方法的類這種視覺分層的優(yōu)勢就會(huì)非常明顯。3.3 適配范圍和標(biāo)注邏輯目前 Test Code Highlighting 對(duì) ABAP Unit 的標(biāo)注覆蓋還算全面但也不是所有場景都支持。根據(jù)我實(shí)測它主要覆蓋了這些場景TEST方法標(biāo)記AUARDING輔助類的實(shí)例聲明測試替身cl_abap_testdouble及其子類相關(guān)的變量聲明cl_abap_unit_assert類中的斷言方法調(diào)用測試配置類的特殊接口實(shí)現(xiàn)比如帶有if_test_selection的局部類說實(shí)話這套標(biāo)注邏輯是基于語義識(shí)別的所以對(duì)代碼規(guī)范有隱性要求。如果你的測試類里大量使用動(dòng)態(tài)調(diào)用assign component ...這種或者把斷言包在自定義的 helper 方法里而不直接調(diào)用cl_abap_unit_assert那么著色的效果會(huì)被削弱——不是功能壞了而是它識(shí)別不到標(biāo)準(zhǔn)的語義節(jié)點(diǎn)。如果你想提升這個(gè)功能的效果建議在寫測試類時(shí)盡量直接用 ABAP Unit 標(biāo)準(zhǔn) API不要寫中間層封裝。我知道有些團(tuán)隊(duì)喜歡封裝assert_that之類的自定義斷言方法從代碼整潔角度的確可以減少重復(fù)但代價(jià)就是 ADT 的標(biāo)注能力形同虛設(shè)。對(duì)我來說折中的方案是固定的輔助方法可以封裝但核心斷言鏈路仍然調(diào)用標(biāo)準(zhǔn) API這樣既保留了代碼整潔也保住了 Tooling 的可視化能力。4. 一條順滑工作流從需求到失敗定位的完整鏈路4.1 用真實(shí)業(yè)務(wù)場景串起整個(gè)流程前面把兩個(gè)功能的用法都講了一遍現(xiàn)在把它們串成一條完整的工作流。我用一個(gè)很常見的業(yè)務(wù)場景做例子一個(gè)訂單價(jià)格計(jì)算類cl_order_price_calculator里面有個(gè)方法calculate_net_price接收訂單內(nèi)表、返回折扣后的凈價(jià)。這個(gè)類依賴兩個(gè)外部服務(wù)一個(gè)是國家稅率服務(wù)cl_tax_rate_service另一個(gè)是客戶等級(jí)服務(wù)cl_customer_tier_service。寫單元測試時(shí)這兩個(gè)依賴都要 mock否則測試會(huì)受外部系統(tǒng)狀態(tài)影響。整個(gè)工作流分為四個(gè)步驟生成測試類骨架、設(shè)計(jì)測試方法并 mock 依賴、運(yùn)行測試并觀察著色反饋、定位失敗回到業(yè)務(wù)代碼修復(fù)。每一步我都會(huì)結(jié)合實(shí)際操作細(xì)節(jié)講講。4.2 Step 1生成測試類骨架并理解生成物在 ADT 里打開cl_order_price_calculator定位到calculate_net_price方法定義那一行按Ctrl1選擇 Generate ABAP Unit Test Class。確認(rèn)測試類名默認(rèn)是cl_order_price_calculator_test和保存包之后你會(huì)得到類似下面這樣的骨架CLASS cl_order_price_calculator_test DEFINITION FOR TESTING DURATION SHORT RISK LEVEL HARMLESS . PRIVATE SECTION. METHODS calculate_net_price FOR TESTING. ENDCLASS. CLASS cl_order_price_calculator_test IMPLEMENTATION. METHOD calculate_net_price. TODO: test implementation ENDMETHOD. ENDCLASS.注意這個(gè)骨架里還缺很多東西受測類的實(shí)例引用、mock 對(duì)象的聲明、依賴注入的 setter 調(diào)用。這些都要自己補(bǔ)Quick Actions 不會(huì)把業(yè)務(wù)邏輯的測試意圖也猜出來。但我從來不覺得這是缺點(diǎn)——它把最容易出錯(cuò)、最格式化的部分做了把最需要業(yè)務(wù)判斷的部分留給你這才是合理的分工。很多人在生成骨架之后會(huì)忘記一個(gè)事檢查測試類里有沒有生成FOR TESTING的輔助類聲明比如 mock 類。如果沒有你需要自己手動(dòng)聲明。我的習(xí)慣是在骨架類的 private section 里加一塊專門區(qū)域放受測類引用和 mock 引用比如PRIVATE SECTION. DATA cut TYPE REF TO cl_order_price_calculator. DATA tax_service TYPE REF TO cl_tax_rate_service. DATA tier_service TYPE REF TO cl_customer_tier_service.這里的cut是 Class Under Test 的縮寫是我個(gè)人比較喜歡的命名規(guī)范。團(tuán)隊(duì)里也有人用under_test這都無所謂關(guān)鍵是統(tǒng)一。4.3 Step 2設(shè)計(jì)測試方法并利用 MockA 做依賴打樁接下來是設(shè)計(jì)測試方法。因?yàn)槭轻槍?duì)calculate_net_price的測試你要考慮至少這幾類場景正常訂單、折扣邊界、稅率為零的免稅訂單、空訂單列表。我建議為每個(gè)場景寫一個(gè)獨(dú)立的測試方法方法名用calculate_net_price_with_xxx這樣的格式比如METHODS calculate_net_price_with_discount FOR TESTING. METHODS calculate_net_price_tax_free FOR TESTING. METHODS calculate_net_price_empty_cart FOR TESTING.每個(gè)測試方法里先實(shí)例化受測類再用 mock 替換依賴。當(dāng)前 ABAP 環(huán)境里最常用的 mock 手段是cl_abap_testdouble配合get_double方法拿到 mock 引用再通過set_component_exporting配置返回值。我每次寫這種代碼前都會(huì)先看一眼 ADT 的 Quick Actions 有沒有提供輔助有些情況下它能幫我生成cl_abap_testdoubleget_double( )那段聲明但更多時(shí)候還是手寫比較快。注入依賴的方式取決于受測類的設(shè)計(jì)。如果訂單價(jià)格計(jì)算器把稅率服務(wù)對(duì)象放在構(gòu)造函數(shù)里傳遞那測試方法里就需要這樣構(gòu)造cut NEW cl_order_price_calculator( tax_service mock_tax_service tier_service mock_tier_service ).如果你的業(yè)務(wù)類用的是 setter 注入那就在調(diào)用方法前先把 mock 塞進(jìn)去。不管是哪種方式寫完這一步之后代碼里的 mock 調(diào)用、斷言調(diào)用、TEST方法名都會(huì)被 Test Code Highlighting 染上不同的顏色。這時(shí)候掃一眼屏幕你就能確認(rèn)哪些地方是需要重點(diǎn)關(guān)注的核心鏈路。4.4 Step 3運(yùn)行測試并利用著色反饋快速做代碼走查運(yùn)行 ABAP Unit 測試在 ADT 里有兩種常見方式。一種是打開測試類用運(yùn)行配置里選 ABAP Unit Test 直接跑另一種更常用的是在業(yè)務(wù)類里右鍵選 Run As ABAP Unit Test。我個(gè)人推薦第二種因?yàn)樗鼤?huì)把運(yùn)行范圍限制在當(dāng)前類相關(guān)的測試類上不需要單獨(dú)維護(hù)測試運(yùn)行配置。測試跑完之后ADT 的 Test Runner 標(biāo)簽頁會(huì)給出結(jié)果列表。這個(gè)列表可以展開每個(gè)測試方法看到斷言詳情、調(diào)用棧、以及失敗時(shí)的消息。我在這里要強(qiáng)調(diào)的是不要等測試失敗了才開始看代碼而是應(yīng)該在提交測試代碼前就通過 Test Code Highlighting 做一次視覺走查。具體做法是打開測試類審視一遍顏色分布。如果發(fā)現(xiàn)某個(gè)測試方法完全沒有斷言高亮色基本可以斷定這個(gè)測試方法沒寫斷言屬于假測試如果發(fā)現(xiàn)某段代碼的顏色和預(yù)期不符比如本應(yīng)是 mock 調(diào)用卻沒有被標(biāo)注說明測試代碼可能沒有走標(biāo)準(zhǔn) double API這時(shí)候就要主動(dòng)檢查是否符合規(guī)范。這種檢查方式比逐行讀代碼快得多而且能抓出很多看起來在測試、實(shí)際什么都沒驗(yàn)證的水測試。我團(tuán)隊(duì)里有個(gè)同事曾經(jīng)寫過一個(gè)打印日志的測試方法跑了綠但方法里根本沒有斷言。他當(dāng)時(shí)還覺得反正綠了就行結(jié)果后來業(yè)務(wù)邏輯改壞了這個(gè)場景測試還是綠的。用了這種方法之后一眼就能看出測試方法有沒有斷言再也沒人寫這種假測試了。4.5 Step 4定位失敗時(shí)用好調(diào)用棧和關(guān)聯(lián)導(dǎo)航測試失敗的定位環(huán)節(jié)是快與穩(wěn)最直觀的體現(xiàn)。當(dāng)某個(gè)測試方法失敗時(shí)Test Runner 會(huì)顯示完整的調(diào)用棧包括業(yè)務(wù)類的具體行號(hào)。我的習(xí)慣是直接在 Stack 里點(diǎn)業(yè)務(wù)類的那個(gè) frameADT 會(huì)跳到對(duì)應(yīng)代碼行。那個(gè)地方就是需要你修復(fù)的 bug 所在。不過要注意ABAP Unit 失敗時(shí)如果真的跳到了業(yè)務(wù)代碼不一定就是那行有 bug——多數(shù)情況是斷言的預(yù)期值不對(duì)或者 mock 返回值配置錯(cuò)了。所以我的判斷邏輯是先看是哪個(gè)斷言失敗了再看斷言兩邊的變量值差了多少。ADT 的 Test Runner 會(huì)給你顯示 expected 和 actual 的對(duì)比如果差異很大優(yōu)先檢查 mock 配置如果差異很小比如金額差了幾毛錢優(yōu)先檢查舍入邏輯。在這個(gè)環(huán)節(jié)Quick Actions 還有一個(gè)補(bǔ)刀功能你把斷言參數(shù)改好之后光標(biāo)停在那一行按Ctrl1ADT 偶爾會(huì)提供修復(fù)預(yù)期值之類的建議直接幫你把 expected 值替換成 actual 當(dāng)前值。這在維護(hù)舊測試時(shí)特別有用相當(dāng)于一個(gè)自動(dòng)化補(bǔ)丁。5. 踩坑實(shí)錄與高級(jí)技巧5.1 Quick Actions 不彈出和生成質(zhì)量差的常見原因我用這套工作流快兩年了有些坑可以說是我踩過之后才徹底明白的。第一個(gè)坑是 Quick Actions 生成測試類時(shí)只導(dǎo)出了方法名沒導(dǎo)出參數(shù)結(jié)構(gòu)。后來發(fā)現(xiàn)原因是我只選中了方法名而沒有選中整個(gè)方法簽名。如果把光標(biāo)停在方法定義的任意位置、而不是高亮選中名字生成時(shí)會(huì)以當(dāng)前方法上下文為準(zhǔn)參數(shù)結(jié)構(gòu)就能全部帶上。關(guān)于這一點(diǎn)操作習(xí)慣真的很重要。第二個(gè)坑是某些情況下生成測試類時(shí)會(huì)彈出一個(gè)對(duì)話框問是否創(chuàng)建local test class。如果你選擇 Yes測試類會(huì)被生成在主程序里的CLASS ... DEFINITION FOR TESTING區(qū)塊內(nèi)。這在程序比較大時(shí)其實(shí)是好事因?yàn)闇y試類隨主程序一起激活、一起傳輸部署方便但如果你使用的是可傳輸?shù)臏y試包含就不要選 local test class否則會(huì)導(dǎo)致測試代碼重復(fù)維護(hù)。我的建議是新寫功能優(yōu)先用可傳輸?shù)臏y試包含老程序維護(hù)用 local test class兩邊并存也沒問題但別在一個(gè)類里來回轉(zhuǎn)換遷移成本挺高的。第三個(gè)坑也是最常見的Quick Actions 的生成質(zhì)量極其依賴當(dāng)前編輯器里代碼的可解析性。如果你的業(yè)務(wù)類引用了另一個(gè)未激活的對(duì)象或者動(dòng)態(tài)類型解析不出來ADT 會(huì)直接拒絕生成測試類。這種情況下很多人以為是 ADT 卡了其實(shí)是代碼還沒就緒。處理方法就是先把業(yè)務(wù)類保存、激活確保能正常編譯再重新觸發(fā)。5.2 Test Code Highlighting 的幾個(gè)實(shí)用配置建議關(guān)于 Highlighting 的配置我另外想提三個(gè)建議。第一個(gè)建議不只是測試類你可以在 Preferences 里把 Test Code Highlighting 的色值調(diào)成和你平時(shí)的暗色主題相配避免顏色反差過大刺眼。默認(rèn)色值在某些主題下偏淡我一般會(huì)把斷言色調(diào)到飽和度更高一些這樣掃視時(shí)更醒目。第二個(gè)建議不要只開 Test Code Highlighting還要同時(shí)開 Test Coverage 的著色。Coverage 著色會(huì)讓你在查看業(yè)務(wù)類代碼時(shí)看到哪些行被測試覆蓋到了、哪些沒有。這配合起來比單純看覆蓋率報(bào)表直觀得多。在業(yè)務(wù)類里打開 Coverage 高亮紅色區(qū)域就是沒測到的代碼行對(duì)著紅色補(bǔ)測試效率極高。第三個(gè)建議把 Test Code Highlighting 的開關(guān)和你的團(tuán)隊(duì)標(biāo)準(zhǔn)化綁定。我們團(tuán)隊(duì)在每個(gè)項(xiàng)目交付前都會(huì)統(tǒng)一檢查一次成員的工作區(qū)配置確保開啟了著色。這個(gè)看起來是小細(xì)節(jié)但對(duì)新人尤其重要——新人在沒有高亮的世界里寫測試很難通過顏色反饋快速判斷自己寫的代碼算不算真測試很容易養(yǎng)成寫假測試的壞習(xí)慣。5.3 一套我認(rèn)為比較穩(wěn)健的 ABAP Unit 使用規(guī)范順著工作流的思路我把自己在項(xiàng)目中沉淀下來的一套規(guī)范列出來不一定適用于所有團(tuán)隊(duì)但可以作為參考基線測試類命名統(tǒng)一用cl_受測類_test避免出現(xiàn)test_cl_受測類這種風(fēng)格不統(tǒng)一。每個(gè)公開方法至少有一個(gè)正向測試和一個(gè)邊界測試。邊界測試不是可選項(xiàng)尤其是金額、日期、數(shù)量這類容易出隱蔽 bug 的領(lǐng)域。Mock 優(yōu)先級(jí)嚴(yán)格一致能用cl_abap_testdouble就用它來做行為驗(yàn)證不要?jiǎng)硬粍?dòng)寫一堆真實(shí)實(shí)現(xiàn)類來充當(dāng)測試替身。斷言集中在每個(gè)測試方法的最后一部分不要在斷言后還夾帶業(yè)務(wù)邏輯調(diào)用否則排查問題時(shí)定位成本高。測試數(shù)據(jù)和測試代碼一起維護(hù)版本。這一點(diǎn)在 S/4HANA 的項(xiàng)目里尤其重要因?yàn)闇y試數(shù)據(jù)一旦和代碼版本不同步測試結(jié)果是完全不可信的。5.4 從能跑到跑得快我最后想分享的一個(gè)細(xì)節(jié)最后再說一個(gè)細(xì)節(jié)上的技巧。你可以在測試類的運(yùn)行配置里把 ABAP Unit Test 的并行執(zhí)行選項(xiàng)打開。ADT 默認(rèn)是串行跑測試方法的當(dāng)時(shí)方法數(shù)量少還好一旦測試類里有了幾十個(gè)方法串行耗時(shí)能明顯拖慢調(diào)試節(jié)奏。并行執(zhí)行打開之后多個(gè)測試方法會(huì)分散到后臺(tái)作業(yè)里跑結(jié)果匯總到同一個(gè) Test Runner 頁面。需要注意的只是測試方法之間絕對(duì)不能有相互依賴比如用靜態(tài)變量共享狀態(tài)之類的操作并行執(zhí)行下就會(huì)隨機(jī)出問題。這個(gè)細(xì)節(jié)是我在一次上線前突擊補(bǔ)測試時(shí)發(fā)現(xiàn)的。當(dāng)時(shí)測試方法從十幾個(gè)漲到六十多個(gè)串行執(zhí)行一次要將近三分鐘后來開啟并行后一分半不到就跑完了體感差別非常大。如果你也在維護(hù)一套大測試類建議盡早開啟。6. 這套工作流下一步還能怎么擴(kuò)展說到后續(xù)擴(kuò)展的空間我自己的規(guī)劃是先適配更多帶TEST注解的本地類場景。目前這套流程在普通的報(bào)表/函數(shù)類上跑得很順但在涉及 BAdI 增強(qiáng)和用戶出口的測試上還不夠順手因?yàn)檫@些場景的依賴注入往往需要跑完整的框架環(huán)境。另一個(gè)可以發(fā)展的方向是把它延伸到 ABAP 云的 CI 驗(yàn)證上。ADT 里跑單元測試只是第一步把測試納入到發(fā)布流水線里讓每次代碼提交都自動(dòng)觸發(fā)測試才是真正讓 ABAP Unit 進(jìn)入常態(tài)化質(zhì)量保障的關(guān)鍵。這個(gè)思路其實(shí)和標(biāo)題里的又快又穩(wěn)是同一件事的兩面——在本地寫測試、用工具加速在 CI 里跑測試、把穩(wěn)定性固化下來。對(duì)我個(gè)人而言從手動(dòng)敲測試類到用 Quick Actions 生成骨架從逐行讀測試源碼到靠 Test Code Highlighting 一眼掃出問題區(qū)域這個(gè)轉(zhuǎn)變帶來的不只是效率提升更是心態(tài)上的變化——當(dāng)你不再覺得寫測試是負(fù)擔(dān)的時(shí)候代碼質(zhì)量自然會(huì)往上走。我建議手里有 S/4HANA 項(xiàng)目的朋友今天就可以先打開 Preferences 把 Test Code Highlighting 開啟再找一個(gè)平時(shí)要寫測試的類試一次Ctrl1。這兩個(gè)動(dòng)作加起來不會(huì)超過十分鐘但接下來的每次測試迭代都會(huì)明顯不一樣。