單位vs集成測試
1）為什麼要區分測試類型
正確的測試粒度使開發可預測：單位快速廉價地捕獲邏輯缺陷；集成測試模塊捆綁、實際傳輸和「粘合劑」。他們一起減少了倒退並加快了發行速度。
2）定義和界限
單位測試
隔離檢查小行為單位（函數、類、用例）。
已更換外部約束（mock/stub/fake）。
快速（ms-xx ms），確定性。
集成測試
檢查多個實際組件的交互：DB、經紀人（Kafka/RabbitMQ）、HTTP/gRPC、文件系統、緩存。
最低限度的莫克，真正的協議。
速度更慢（數百毫秒），支持成本更高。
3）測試金字塔（不是冰角）
基礎：單位（數量為70-80％）-便宜，快速。
中層：Integration/Component （15-25%）-關鍵路徑和合同。
頂部：E2E/UX/Exploratory（5-10％）-最低限度就足夠了。
側面：靜態分析/Lint/類型檢查和模擬測試作為質量放大器。
4）給單位什麼，什麼是整合
5）數據和虛構
Unit
Inline fixtures/售票員（工廠方法）。
邊界值的表測試（table driven）。
不變量的基於屬性的方法（例如，「借方總和=借方總和」）。
Integration
Hermetic環境：Testcontainers/Docker Compose提出「postgres+redis+kafka+wiremock」。
在DB/緩存中初始種子，並在之後清除（事務/滾回，跟蹤器）。
時鐘/計時器是假的（受控的），否則是小瓶。
6）工具和模式
Mocks/Stubs/Fakes/Spies:
Stub是固定響應（便宜）。
Mock-驗證交互/呼叫數。
Fake是一種簡化的實現（例如In-Memory Repo）。
合同測試（CDC）：基於客戶的Pact/Swagger-捕獲客戶期望並檢查提供商。
WireMock/MockServer是用於第三方服務的HTTP存根。
Testcontainers是本地和CI中沒有「動物園」的現場DB/經紀人。
7）示例
7.1單位：支付水平性（pseudocode）
python def test_idempotent_create_payment_returns_same_id():
repo = InMemoryPayments()
service = Payments(repo)
first = service. create(amount=100, key="abc")
second = service. create(amount=100, key="abc")
assert first. id == second. id assert repo. count() == 17.2 Integration： webhook簽名（HMAC）+重播
bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q- WireMock用「X-Timestamp」和簽名給出了事件。
- 應用程序檢查HMAC，通過「event_id」進行重復消除，5秒鐘後的重播不會產生雙倍。
- 我們檢查「200」並且記錄是唯一的。
7.3 CDC：客戶與提供商的合同
客戶形成Pact（等待：「POST/v1/payout」 → 「201」帶有電路）。
CI的提供商在其展位上運行合同驗證。
8）速度,平行度,長笛
單位必須工作<100毫秒；數據包-秒。
整合-跨容器/端口並行；在啟動時使用遷移。
- 受控時間（假時鐘），
- 「對顯式事件的期望」而不是「睡眠」，
- 穩定的閾值（帶有抖動器的轉子進行確定性測試）。
9）質量指標
Coverage（行/分支）：有利於觀察趨勢,但不適用於目標。
Mutation testing （PIT/Mutmut）：顯示測試是否「殺死」虛假變化是關聯的真正力量。
Test duration and flaky rate：生長時的差異。
防禦集合：在生產前截獲的錯誤比例。
10）嵌入到CI/CD中
Jobs：單位→ integration → e2e（服務粉絲）。
依存緩存，與DB/語言/版本的矩陣並行。
報告：JUnit/Allure+容器日誌工件（跌落時）。
Gate：「綠色單位+關鍵集成」-警戒條件；e2e-在夜間。
yaml strategy:
matrix:
db: [postgres14, postgres16]
steps:
- run: docker run -d --name db -e POSTGRES_PASSWORD=pw postgres:${{ matrix. db }}
- run: pytest -m "unit" -q
- run: pytest -m "integration" -q11）微服務與活動
服務合同：OpenAPI/Protobuf轉換；兼容性測試（背面）。
Event-driven:
單位：映射域事件和不變量。
整合：真實經紀人（Kafka）發布/訂閱，outbox/inbox語義，單次模仿（至少是idempotent）。
復制/復制/重新排序（訂單外部）測試。
12）集成中的數據和隔離
每個測試都→ 獨特的電路/DB（Testcontainers JDBC URL'？TC_TMPFS =/var/lib/postgresql/data：rw'）。
交易偽造（begin→run→rollback）加快了清潔。
對於Redis/緩存,關鍵前綴是「test： ${RUN_ID}：」和「FLUSHDB」。
13） iGaming/財務細節
金錢和限制：基於屬性的不變量測試（余額≥ 0，總限制）。
監管：日誌驗證（審計日誌寫）,不可變事件。
付款/PSP：HMAC/mTLS集成測試，「Retry-After」，冪等，dedup'jti'。
負責任的遊戲：閾值/拳頭規則測試；fake clock上的「vchera→segodnya」。
14）反模式
提高DB/NTTR的「單位」已經是整合（混淆層並減慢CI）。
高覆蓋率以空白陳述為代價（「覆蓋但未驗證」）。
在需要合同的地方清洗第三方服務邏輯（更新時中斷）。
使用「sleep （5）」測試而不是對事件/條件的期望。
用於並行測試→比賽和長笛的一般測試DB。
15）準備就緒支票清單
- 金字塔定義為：按運行時間計算的Unit/Integration/E2E份額和目標的百分比。
- 單位是隔離的，快速的，覆蓋邊界值和不變量。
- Integration使用恒溫環境（Testcontainers/Compose），沒有共享狀態。
- 合同測試（OpenAPI/Pact）在CI中進行了驗證。
- 測試數據-可管理：seed/rollback/前綴, fake clock。
- 並行運行、JUnit/Allure報告、容器日誌工件。
- 度量標準：持續時間,flaky rate, mutation分數；降解的差異。
- 支付/webhook腳本：HMAC/mTLS, retrais, Idempentity, dedup。
- 策略文檔和測試模板示例。
16) TL;DR
單位-邏輯的最大值，環境的最小值；Integration是moks的最小值，是現實主義的最大值。保持金字塔：快速單元捕獲80%的缺陷,Integration確認韌帶和合同。使用恒溫容器、合同測試、假時鐘和並發性。不僅要測量覆蓋率，還要測量比分和比例。特別檢查付款/網絡掛鉤路徑：簽名、轉發和等效性。