Quartz 5

test_guide

6 min read

SearchAdd 測試導覽

這份文件只處理一件事：

  • 幫接手 search_add 的工程師快速理解 tests/SearchAddStep*IntegrationTest.php 在測什麼

這批 Step 測試的命名來源，不是業務流程名稱，而是 legacy 重寫時的切分步驟。
來源文件在舊專案：

  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/REWRITE_STEPS.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_2_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_3_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_4_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_5_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_6_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_7_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_8_TICKET.md
  • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_9_TICKET.md

怎麼看這批測試

先記住一件事：

  • Step 2 到 Step 9 是「新專案重寫順序」
  • 不是 runtime 真正的執行順序
  • 也不是使用者會理解的 API 階段名稱

所以這批測試比較像：

  • rewrite/cutover 驗收測試

不是：

  • 最適合新人第一眼理解業務規則的語意化測試

如果你要快速排查，建議順序：

  1. 先看 request_lifecycle.md
  2. 再看本文件對應哪一個 Step
  3. 最後才進該支 test class 看 fixture 和 assertion

Step 對照表

Step 2

  • 測試檔：tests/SearchAddStep2IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_2_TICKET.md
  • 核心目的：
    • existing session user 建單主線
    • actor resolution
    • quote_requests 主表建立
  • 刻意不測：
    • auto signup
    • request 附屬表
    • auto quote

Step 3

  • 測試檔：tests/SearchAddStep3IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_3_TICKET.md
  • 核心目的：
    • auto signup
    • actor fallback
    • 建單前核心風控
  • 典型規則：
    • phone verified
    • blocked user
    • duplicate request
    • overseas phone

Step 4

  • 測試檔：tests/SearchAddStep4IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_4_TICKET.md
  • 核心目的：
    • request 建立後的同步附屬資料寫入
  • 典型寫表：
    • quote_form_submissions
    • quote_form_submission_fields
    • quote_request_landing_pages
    • quote_request_logs
    • quote_activities

Step 5

  • 測試檔：tests/SearchAddStep5IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_5_TICKET.md
  • 核心目的：
    • auto quote match
    • bid 建立前的候選過濾
    • quote_request_match_infos / read_segment_9_matches
  • 典型規則：
    • balance
    • read segment
    • ibon specific-user rule

Step 6

  • 測試檔：tests/SearchAddStep6IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_6_TICKET.md
  • 核心目的：
    • bid finalize
    • pricing success / fallback
    • quote_bid_detect_contents
    • submit quote activity

Step 7

  • 測試檔：tests/SearchAddStep7IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_7_TICKET.md
  • 核心目的：
    • special flow
    • preserve / invitation
    • direct reserve
    • authorized mode
    • direct user
  • 補充：
    • 這支最容易混到 queue / transaction / reserve / activity 驗證
    • 看測試時先判斷它在保哪個特殊分支

Step 8

  • 測試檔：tests/SearchAddStep8IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_8_TICKET.md
  • 核心目的：
    • signup / social / referral / external integration 殘差
    • Apple / Google / Facebook
    • fetnet / 55688 / referral / security hash

Step 9

  • 測試檔：tests/SearchAddStep9IntegrationTest.php
  • 對應 legacy ticket：
    • get-lancer-php56/scripts/api_test/suites/search_add/docs/rewrite/STEP_9_TICKET.md
  • 核心目的：
    • booking
    • second-link
    • abnormal / tracking / cutover 收尾
    • async / task 類最終驗收

閱讀建議

如果你是第一次接手：

  1. 先理解 Step 是 rewrite phase，不是 business phase
  2. 每次只讀一支 test class
  3. 先看 class 頂部註解，再看 test method 名稱
  4. 最後才追 fixture helper

如果你是要改某條規則：

  1. 先找它屬於哪個 Step
  2. 回頭看對應 legacy ticket
  3. 再決定要不要補更語意化的專屬測試，例如：
    • IbonFlowTest
    • AuthorizedFlowTest
    • BookingFlowTest

Special Flow 名詞白話表

這些名稱在 Step 7 與 Step 9 很常出現，但對第一次接手的人不夠直觀。

Authorized

  • 指的是：客戶指定某一位專家來接這張單
  • 常見特徵：
    • match_type = Authorize
    • request 帶 quote_service_id
  • 白話理解：
    • 不是系統自己去配一批 provider
    • 而是先對指定的那位 provider 建 bid，再進 contact 後處理

Preserve

  • 指的是：保留或回補某位既有 provider 的 invitation 流程
  • 白話理解：
    • 這張 request 不是走一般 auto quote 主線
    • 而是把某位特定 provider 重新帶回這張單

Direct Reserve

  • 指的是：直接預約某位 provider
  • 白話理解：
    • 不只建 bid
    • 還要補 reservation / pause event / message 類 side effects

Direct User

  • 指的是：直接指定某位 provider user 來對接
  • 白話理解：
    • 和一般 auto match 不同
    • 不是靠候選池自己挑人，而是直接建立特定 user/provider 的對應關係

Booking

  • 指的是：booking shop user 送出的 request
  • 白話理解：
    • 這類 request 有自己的 request metadata、task 與 downstream 規則
    • 不完全等同一般 consumer request
  • 指的是：R2 request 與前一筆 R1 request 的關聯
  • 白話理解：
    • 某些來源下，這張新 request 不是完全獨立
    • 系統要記住它和前一筆 request 的關係，必要時補排前一筆 newQuoteRequest

長期建議

這批 Step 測試適合保留，因為它們代表 rewrite/cutover 驗收。

但未來如果要讓新同事更快上手，建議逐步補一層語意化測試：

  • IbonFlowTest.php
  • AuthorizedFlowTest.php
  • BookingFlowTest.php
  • SecondLinkFlowTest.php

這樣：

  • Step 測試保 rewrite 驗收
  • 語意化測試保業務規則理解

兩層並存會比現在只有 Step 系列更容易維護。

Graph View