前言
在一般電商系統中，測試覆蓋率不足的代價可能是購物車金額算錯或訂單重複成立；但在護理資訊系統（NIS）與醫療電子病歷系統中，程式碼的瑕疵代價是病患安全與醫療糾紛——一次併發競爭造成的重複給藥、一場因邏輯漏洞未發出的敗血症高燒警報，或是一筆斷網重連時遺漏的體徵數據，都可能直接危及生命。

在前面的單元中，我們打造了涵蓋「三讀五對 BCMA 引擎」、「NEWS 早期預警演算法」、「PostgreSQL 行級鎖給藥排程」以及「FHIR 轉譯適配器」的完整後端服務。

今天我們將建立高覆蓋率的自動化測試防禦網：
1.單元測試（Unit Tests）： 使用 Jest 深入模擬臨床極端邊界（如休克低血壓、跨日頻率計算、生理極限值）。
2.端到端整合測試（E2E / Integration Tests）： 使用 Supertest 結合真實 PostgreSQL 容器，模擬病房晨間尖峰的並行高頻寫入（Race Condition & Concurrency），嚴格驗證給藥排程的排他鎖是否真正防住「雙護理師同時扣帳」！

一、測試金字塔與臨床測試策略
針對醫療場域的特性，我們規劃三層測試架構：
二、單元測試：窮舉臨床極端情境與邊界值
我們聚焦測試兩個核心臨床純函式引擎：NEWS 2 評分計算器與 三讀五對 BCMA 比對器。

1. NEWS 2 極端邊界單元測試 (tests/unit/news-score.spec.ts)
2. BCMA 三讀五對防錯引擎單元測試 (tests/unit/bcma-engine.spec.ts)
   

三、整合測試：模擬臨床高併發寫入與競爭條件（Race Condition）
在急性病房最驚險的情境之一：病患處方開立了強心劑或抗生素，白班護理師與實習護理師在推車與床邊 PDA 同步作業，若兩人在同一毫秒內掃描條碼並按下確認給藥，後端是否會重複扣帳與施打？

我們在 Day 19 使用了 PostgreSQL 的 SELECT ... FOR UPDATE 行級悲觀鎖。現在我們要撰寫真並行測試（True Concurrent Integration Test），使用 Promise.all 同時發射 20 個 HTTP 請求搶扣同一筆排程，驗證系統能否堅守「僅 1 筆成功，其餘 19 筆回傳 409 Conflict」的鐵律。

高併發整合測試腳本 (tests/integration/medication-concurrency.spec.ts)

四、批次量測寫入的原子性（All-or-Nothing）整合測試
在 Day 16 的批次體徵 API 中，若一次送入 5 位病患數據，其中第 4 位因帶有非法格式導致失敗，系統是否能確保資料庫交易（Transaction）完美回滾，不留髒資料？

五、執行測試與覆蓋率報告（CI 指令）
在 package.json 配置專屬測試指令與覆蓋率門檻要求：

小結
今天我們為整套護理資訊系統拉起了堅實的安全防線：
1.針對臨床演算法（NEWS 2、三讀五對 BCMA）設計了窮舉式的單元邊界測試。
2.運用 Supertest 模擬了病房尖峰情境下的 20 執行緒高併發給藥，以實驗證實 PostgreSQL 行級鎖可 100% 杜絕重複扣帳與用藥事故。
3.驗證了批次量測寫入的 ACID 資料庫交易回滾，杜絕零碎不完整的醫療髒資料。

品質驗證確認無虞後，明天 Day 28 我們將邁入運維上線的核心篇章：Docker 容器化部署——全系統多容器編排實戰（NIS 核心 + PostgreSQL + Redis + HAPI FHIR）！