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