指南：Jest、pytest 與路徑感知的 CI 測試流水線)
后端前端移動開發(fā)【免費下載鏈接】SparkyFitnessSparkyFitness: Built for Families. Powered by AI. Track food, fitness, water, and health — together.項目地址https://gitcode.com/gh_mirrors/sp/SparkyFitness點擊查看免費下載導讀SparkyFitness 是一個橫跨前端Vite React、后端Node.js Express、移動端React Native Expo與 Garmin 微服務Python的多倉組件項目。本文以倉庫開發(fā)者文檔 docs/src/developer/testing.md 為核心骨架結合 .github/workflows/ci-tests.yml 及各子項目的真實配置與測試用例系統(tǒng)講解四個組件的本地測試命令、統(tǒng)一的 Mock 編寫規(guī)范、基于路徑變更檢測的 CI 流水線以及覆蓋率報告的處理方式。讀完本文你將掌握如何在本地快速跑通任意組件的測試、如何按倉庫既有模式編寫可維護的前端組件測試以及理解 CI 中只測受影響組件和數(shù)據(jù)庫遷移雙重校驗的設計思路。一、測試技術?？傆[SparkyFitness 的測試體系按組件選用兩套主流工具鏈組件技術棧測試框架關鍵配置位置SparkyFitnessFrontendVite React TypeScriptJestts-jest jsdompackage.json、setupTests.tsSparkyFitnessServerNode.js Express TypeScriptVitestpackage.json、vitest.config.tsSparkyFitnessMobileReact Native ExpoJestjest-expo presetpackage.json、jest.setup.jsSparkyFitnessGarminPython 微服務pytest unittest 兼容requirements.txt、tests/test_daily_calories.py從源碼結構看這種前端/移動端用 Jest、后端用 Vitest、Python 服務用 pytest的分工既保持了各組件生態(tài)內最成熟的測試實踐如前端 jest-dom 匹配器、后端 Vitest 的 ESM 原生支持又讓每個 CI Job 擁有獨立的依賴與運行環(huán)境互不干擾。二、本地運行測試四個組件的命令清單各組件腳本定義在其自身的 package.json或 Garmin 的依賴清單中以下命令與文檔一致并標注了每個命令在配置文件中的真實出處# Frontend (Vite React) —— 對應 SparkyFitnessFrontend/package.json cd SparkyFitnessFrontend pnpm test # Run tests in watch mode對應 test: jest pnpm test:ci # Run tests once with coverage對應 test:ci: jest --ci --coverage --maxWorkers2 # Backend (Node.js Express) —— 對應 SparkyFitnessServer/package.json cd SparkyFitnessServer pnpm test # Run tests in watch mode實際為 test: vitest runtest:watch: vitest pnpm test:ci # Run tests once with coveragetest:ci: vitest run --coverage --reporterverbose # Mobile (React Native Expo) —— 對應 SparkyFitnessMobile/package.json cd SparkyFitnessMobile npm run test:run # Run tests oncetest:run: jest npm run test:ci # Run tests once with coveragetest:ci: jest --ci --coverage --maxWorkers2 # Garmin Microservice (Python) cd SparkyFitnessGarmin pytest --cov. --cov-reporthtml幾點值得注意的細節(jié)CI 模式的共性三個 JS/TS 組件在test:ci中都使用了--ci標志前端與移動端還帶--maxWorkers2限制并行 Worker 數(shù)避免 CI 資源爭搶后端則改用--reporterverbose輸出更詳細的失敗信息。Watch 模式的差異前端與移動端的pnpm test/npm run test默認進入 Jest watch 模式后端文檔中寫的pnpm test實際執(zhí)行vitest run單次運行如需監(jiān)聽則使用pnpm test:watch即vitest。從 SparkyFitnessServer/package.json 的 scripts 定義可以看出這一差別。驗證鏈CI 在跑測試前還會執(zhí)行各組的validate腳本——前端為typecheck lint format:check knip后端為typecheck lint format:check移動端則在 i18n 與肌肉圖生成校驗之外疊加 typecheck、lint、knip 與原生本地化檢查。測試與靜態(tài)檢查在流水線中是兩道并行的質量閘門。三、CI 工作流路徑感知的按需測試倉庫的 CI 流水線定義在 .github/workflows/ci-tests.yml在 pull request 以及推送到main分支時觸發(fā)。與每次全量跑所有測試的樸素做法不同該流水線借助 dorny/paths-filter 做路徑變更檢測只對實際改動的組件運行測試從而顯著壓縮 PR 的等待時間。觸發(fā)條件與組件映射表工作流最外層通過paths限定觸發(fā)范圍——只有四個組件目錄、移動端/iOS 相關文件或工作流自身發(fā)生變化時才會啟動組件觸發(fā)路徑包管理器測試命令對應 CI JobFrontendSparkyFitnessFrontend/**pnpmpnpm run test:cifrontend-testsMobileSparkyFitnessMobile/**npmnpm run test:cimobile-testsServerSparkyFitnessServer/**pnpmpnpm run test:ciserver-testsGarminSparkyFitnessGarmin/**pippytestgarmin-tests注Mobile 一列文檔標注 npm但實際工作流中移動端 Job 仍使用pnpm install --frozen-lockfile安裝依賴測試命令則為pnpm run test:ci見 ci-tests.yml 的mobile-tests步驟與 SparkyFitnessMobile/package.json 中定義的腳本一致此處以工作流實際內容為準。兩階段執(zhí)行模型流水線由第一個changesJob 和四個/六個后續(xù)測試 Job 組成測試 Job 均通過needs: changes與if: needs.changes.outputs.component true做條件門控changesDetect Changesactions/checkoutv4檢出代碼后用dorny/paths-filterv2按五組過濾器frontend、mobile、server、garmin、migrations計算哪些組件有改動并將結果以 job outputs 形式暴露。按需測試 Jobfrontend-tests、mobile-tests、server-tests、garmin-tests各自只在自己的目錄working-directory下執(zhí)行migration-check與migration-upgrade-check則僅在遷移相關文件變化時啟動詳見下文。各測試 Job 的通用流程可概括為actions/checkoutv4→pnpm/action-setupv4安裝 pnpm →actions/setup-nodev4配置指定 Node 版本并緩存 pnpm 依賴cache-dependency-path: pnpm-lock.yaml→pnpm install --frozen-lockfile鎖定版本安裝 → 運行validate類型檢查、Lint、格式化→ 運行test:ci并輸出覆蓋率 →actions/upload-artifactv4上傳 coverage 目錄retention-days: 7保留 7 天。各 Job 的獨有細節(jié)Node 版本前端、后端、遷移 Job 使用 Node 24移動端使用 Node 20見各 Job 的setup-node步驟與各自依賴的運行時要求匹配。后端測試的密鑰處理server-testsJob 環(huán)境特意不設置SPARKY_FITNESS_API_ENCRYPTION_KEY與BETTER_AUTH_SECRET而是由 vitest.config.ts 在每次運行時用crypto.randomBytes生成隨機回退值。這樣倉庫中不落任何密鑰字面量避免 GitGuardian 等密鑰掃描器在每次 push 時報警。后端 Job 還設置了SKIP_RLS_MATRIX: 1因為該 Job 沒有數(shù)據(jù)庫RLS 權限矩陣測試會被跳過留待專門的遷移 Job 在真實 Postgres 上驗證。Garmin Job使用actions/setup-pythonv5Python 3.12 pip 緩存先pip install -r requirements.txt再補裝pytest pytest-cov執(zhí)行pytest --cov. --cov-reportxml --cov-reporthtml當目錄中不存在測試時打印提示跳過且該步驟配置了continue-on-error: true覆蓋率上傳仍通過if: always()保證執(zhí)行。數(shù)據(jù)庫遷移的雙重校驗這是流水線中值得單獨講透的部分。migration-checkFresh-install Migrations與migration-upgrade-checkUpgrade-path Migrations共享同一個migrations過濾條件覆蓋路徑包括SparkyFitnessServer/db/migrations/**、rls_policies.sql、grantPermissions.ts、dbMigrations.ts、applyRlsPolicies.ts、initializeDatabase.ts及相關集成測試文件。兩個 Job 都通過services拉起postgres:18.3-alpine容器POSTGRES_DB: sparky_test健康檢查pg_isreadymigration-check全新安裝路徑在空庫上并行啟動兩個pnpm run test:migrations進程tests/migrate.script.ts入口驗證并發(fā)初始化時數(shù)據(jù)庫鎖與冪等機制的正確性隨后依次執(zhí)行 RLS 權限矩陣、Strava 清理、OIDC 提供方、Better Auth schema對應歷史上 #2469/#2470 認證中斷事故的回歸測試、登錄限流、provider 同步聲明等集成測試并固定SPARKY_FITNESS_FRONTEND_URLhttp://localhost:3004以保證 Better Auth 實例構建方式一致。migration-upgrade-check升級路徑fetch-depth: 0拉取完整歷史先用git checkout ${BASE_SHA}把基礎分支的 SQL 遷移文件換入并跑一遍test:migrations再換回 PR 的遷移文件跑第二遍。由于schema_migrations表在兩次運行間保留第二遍只會應用新增遷移——恰好模擬存量部署平滑升級的真實場景專門捕獲那些只在已填充數(shù)據(jù)的 schema 上才會暴露的遷移問題。四、測試文件布局文檔給出了各組件測試目錄的組織方式結合倉庫實際文件結構可進一步確認SparkyFitnessFrontend/ src/tests/ setupTests.ts # 全局測試初始化jest-dom、polyfills test-utils.tsx # renderWithClient 測試渲染輔助 stubs/ # betterAuth、react-markdown 等第三方模塊樁 components/ # 組件測試與組件領域一一對應 MealBuilder.test.tsx MealManagement.test.tsx MealPlanCalendar.test.tsx SparkyFitnessServer/ tests/ # 后端單元與集成測試*.test.ts被 vitest include 捕獲 migrate.script.ts # 數(shù)據(jù)庫遷移執(zhí)行腳本test:migrations 入口 SparkyFitnessMobile/ __tests__/ components/ # 移動端組件測試 hooks/ # 自定義 Hook 測試 services/ # 服務層測試 screens/ # 屏幕級測試 localization/ # i18n 本地化測試從源碼看前端測試集中在src/tests/而非與組件文件同目錄后端則統(tǒng)一放在tests/下由 vitest.config.ts 的include: [**/tests/**/*.test.ts]收集移動端 Jest 配置還通過testPathIgnorePatterns排除了__tests__/helpers/、__tests__/hooks/queryTestUtils.ts等輔助文件避免輔助代碼被誤判為測試。五、編寫前端測試統(tǒng)一的 Mock 模式文檔強調所有前端組件測試遵循一致的 Mock 策略倉庫中最具代表性的例子是 MealBuilder.test.tsx該文件中對waitFor/renderWithClient/initialFoods的組合使用共出現(xiàn) 45 處是前端測試密集區(qū)的典型樣本。標準流程如下// 1. Mock i18n —— 返回回退字符串或翻譯 key jest.mock(react-i18next, () ({ useTranslation: () ({ t: (key: string, defaultValueOrOpts?: string | Recordstring, unknown) { if (typeof defaultValueOrOpts string) return defaultValueOrOpts; if (defaultValueOrOpts typeof defaultValueOrOpts object defaultValue in defaultValueOrOpts) { return defaultValueOrOpts.defaultValue as string; } return key; }, }), })); // 2. Mock contexts jest.mock(/contexts/ActiveUserContext, () ({ useActiveUser: () ({ activeUserId: test-user-id }), })); jest.mock(/contexts/PreferencesContext, () ({ usePreferences: () ({ loggingLevel: debug, itemDisplayLimit: 100 }), })); // 3. Mock toast jest.mock(/hooks/use-toast, () ({ toast: jest.fn() })); // 4. Mock logging jest.mock(/utils/logging, () ({ debug: jest.fn(), info: jest.fn(), warn: jest.fn(), error: jest.fn(), })); // 5. Mock services with trackable fns —— 用可斷言的 mock 函數(shù)包一層便于后續(xù)斷言調用 const mockGetMeals jest.fn(); jest.mock(/services/mealService, () ({ getMeals: (...args: unknown[]) mockGetMeals(...args), }));倉庫真實測試中的進階變體對照 MealBuilder.test.tsx 的開頭部分可以看到文檔模式的落地細節(jié)i18n mock 補全了initReactI18next除useTranslation外還導出了{ type: 3rdParty, init: () {} }避免組件初始化 i18n 實例時報錯。Context mock 攜帶業(yè)務默認值PreferencesContext的 mock 額外返回nutrientDisplayPreferences含view_group: quick_info與可見營養(yǎng)項數(shù)組、energyUnit: kcal與convertEnergy說明 mock 需覆蓋被測組件實際讀取的全部字段。API 服務按模塊整體 mock如jest.mock(/api/Foods/meals, ...)同時提供createMeal、updateMeal、getMealById三個可跟蹤函數(shù)。復雜子組件 stub 化FoodUnitSelector、FoodSearchDialog等子組件被替換為返回帶data-testid的簡單 div將被測組件與子組件實現(xiàn)徹底隔離。beforeEach(() jest.clearAllMocks())保證用例之間互不污染。約定與測試輔助文檔列出的約定在倉庫中得到一一印證測試文件與其組件領域同放于src/tests/components/按*.test.tsx命名使用testing-library/react進行渲染與斷言test-utils.tsx 提供了renderWithClient輔助內部創(chuàng)建retry: false的QueryClient并包裹QueryClientProvider同時掛載 Query/MutationCache 的全局錯誤 toast 處理用waitFor等待異步操作如await waitFor(() expect(screen.getByLabelText(Total Servings)).toBeInTheDocument())等待 API 調用后的 UI 狀態(tài)更新通過initialFoods之類的 props 直接注入數(shù)據(jù)避免依賴交互型子組件MealBuilder即以initialFoods{sampleFoods}注入樣本食物數(shù)據(jù)。六、移動端測試環(huán)境jest-expo 與全局樁移動端測試的復雜度主要來自大量原生模塊。其 Jest 配置SparkyFitnessMobile/package.json 的jest字段使用jest-expopreset 與 jsdom 環(huán)境并通過一份數(shù)百行的 jest.setup.js 集中樁掉無法在 Node 中運行的原生能力標準庫 polyfillTextEncoder/TextDecoderExpo winter 運行時按需安裝 whatwg-url 需要它們本地化與系統(tǒng) APIexpo-localization固定返回en-USexpo-application/expo-constants提供固定版本號健康數(shù)據(jù)橋kingstinct/react-native-healthkit的讀寫與授權 API 全部 mock寫回保存返回帶uuid的樣本對象確保 UUID 跟蹤斷言真實有效react-native-health-connect的權限、讀取、聚合 API 亦全部樁化動畫與手勢react-native-reanimated、react-native-gesture-handler、react-native-keyboard-controller提供鏈式可調用的樁實現(xiàn)保證拖拽排序、手勢等交互代碼在單元測試中可安全執(zhí)行第三方渲染庫victory-native、shopify/react-native-skia、react-native-maps、gorhom/bottom-sheet渲染為帶testID的 View供斷言畫了什么i18n 生產(chǎn)實例文件末尾加載真實的src/localization/i18n并以initImmediate: false同步初始化讓被隔離渲染的組件也能解析英文默認文案而非返回原始 key。同時moduleNameMapper將workspace/shared指向../shared/src/index.ts跨包共享代碼直接在測試中解析 TS 源碼并通過精心編寫的transformIgnorePatterns白名單讓 react-native、expo、react-navigation、workspace/shared、zod、better-auth 等 ESM 包通過 babel 轉換。七、后端測試Vitest 與運行時密鑰策略后端使用 Vitest 且采用globals: true測試文件中可直接使用 describe/it/expect環(huán)境為 Node。兩個值得關注的設計跨包共享代碼解析resolve.alias將workspace/shared指向../shared/src與前端、移動端的 moduleNameMapper 策略一致共享包源碼被直接納入各組件測試。隨機密鑰回退vitest.config.ts測試進程需要SPARKY_FITNESS_API_ENCRYPTION_KEY32 字節(jié) hex與BETTER_AUTH_SECRETbase64配置在讀取倉庫根.env后若缺失則用crypto.randomBytes生成每次運行不同的隨機值注入test.env。因為這些值只在進程內用于加解密與 cookie 簽名不持久化、不跨運行復用隨機生成完全安全同時保證倉庫內沒有任何密鑰字面量——這正是不把秘密寫進代碼的工程實踐在測試層的體現(xiàn)。后端測試腳本一覽SparkyFitnessServer/package.jsontest: vitest run, // 單次運行 test:watch: vitest, // 監(jiān)聽模式 test:coverage: vitest run --coverage, test:ci: vitest run --coverage --reporterverbose, test:migrations: tsx tests/migrate.script.tstest:migrations專供 CI 的遷移 Job 調用配合tests/migrate.script.ts與 Postgres 服務容器完成空庫初始化與升級路徑驗證。八、Garmin 微服務測試pytestGarmin 微服務Python使用 pytest 并帶覆蓋率輸出。倉庫中的 tests/test_daily_calories.py 是典型樣例以unittest.TestCase組織用例通過sys.path.insert將父目錄加入模塊搜索路徑后直接導入service.py的業(yè)務函數(shù)。測試覆蓋了規(guī)范字段解析activeKilocalories/bmrKilocalories/totalKilocalories正確映射為active_calories/bmr_calories/total_calories浮點值別名回退activeCalories/bmrCalories/totalCalories等已知別名在規(guī)范字段缺失時生效且字符串數(shù)字可被正確轉換邊界值保留合法的0剔除None、inf與 not-a-number 等缺失或非法值。本地運行方式pytest --cov. --cov-reporthtmlCI 中則執(zhí)行pytest --cov. --cov-reportxml --cov-reporthtml并將htmlcov/作為構建產(chǎn)物上傳。九、覆蓋率報告與產(chǎn)物管理運行test:ci后各組件會在自身目錄下生成coverage/前端與移動端Garmin 為htmlcov/。CI 中這些目錄通過actions/upload-artifactv4上傳為構建產(chǎn)物retention-days: 7表示保留 7 天后自動清理Job上傳產(chǎn)物名上傳路徑保留天數(shù)frontend-testsfrontend-coverageSparkyFitnessFrontend/coverage/7mobile-testsmobile-coverageSparkyFitnessMobile/coverage/7server-testsserver-coverageSparkyFitnessServer/coverage/7garmin-testsgarmin-coverageSparkyFitnessGarmin/htmlcov/7上傳步驟均使用if: always()即使測試失敗也會保留覆蓋率產(chǎn)物便于事后在 GitHub Actions 的 Artifacts 中下載分析。本地查看覆蓋率時可直接打開 HTML 報告前端/移動端coverage/lcov-report/index.htmlGarminhtmlcov/index.html逐文件瀏覽未覆蓋分支。十、編寫測試的通用建議綜合文檔約定與倉庫實踐可沉淀出以下可復用的編寫準則Mock 一切外部依賴只測被測單元i18n、Context、toast、日志、API 服務、復雜子組件逐一樁化對需要斷言的服務調用用可跟蹤的jest.fn包裹并在測試內斷言調用參數(shù)與次數(shù)。用真實輔助函數(shù)包裹 Provider如renderWithClient統(tǒng)一注入 QueryClient關閉重試避免每個測試重復樣板代碼。異步一律waitForAPI 調用、狀態(tài)更新等異步 UI 斷言放在waitFor中配合screen查詢器與 jest-dom 匹配器toBeInTheDocument、toBeEnabled書寫。通過 props 注入數(shù)據(jù)優(yōu)先用initialFoods這類輸入屬性驅動組件而不是依賴子組件交互來間接準備數(shù)據(jù)。保持 CI 與本地一致本地先跑validatetypecheck/lint/format再跑test:ci與 CI 的檢查順序保持一致避免本地綠、CI 紅。涉及數(shù)據(jù)庫的改動務必關注遷移 Job任何db/migrations/**、RLS 策略或遷移運行器文件的改動都會觸發(fā)兩個需要真實 Postgres 的集成驗證本地可借助 docker-compose 中的數(shù)據(jù)庫服務先行演練。延伸閱讀開發(fā)者文檔目錄架構architecture.md、數(shù)據(jù)庫database.md、權限層級database-security-tiers.md、troubleshooting.md 等配套文檔。前端全局測試初始化jsdom polyfillsmatchMedia、ResizeObserver、PointerEvent與 react-leaflet/leaflet 樁。移動端全局測試初始化Expo 生態(tài)原生模塊的完整 mock 清單。后端測試運行器配置隨機密鑰回退與workspace/shared別名。Garmin 測試樣例Python 側單元測試的編寫范式。贊分享后端前端移動開發(fā)【免費下載鏈接】SparkyFitnessSparkyFitness: Built for Families. Powered by AI. Track food, fitness, water, and health — together.項目地址https://gitcode.com/gh_mirrors/sp/SparkyFitness點擊查看免費下載相關推薦FastLED 的 CI 測試套件指南ci/tests pytest 測試體系全解析FastLED 的 CI 測試套件指南ci/tests pytest 測試體系全解析 FastLED 倉庫在 ci/tests https://link.gi嵌入式物聯(lián)網(wǎng)硬件開發(fā)驅動開發(fā) Transformers 測試指南從 CI 流水線到測試編寫實戰(zhàn) Transformers 測試指南從 CI 流水線到測試編寫實戰(zhàn) 本文是 Transformers 倉庫官方日語版《Testing》文檔的深度解讀人工智能大模型深度學習NLP預訓練微調模型推理服務Perfetto 測試體系實戰(zhàn)指南單元測試、集成測試、Diff 測試與 CI 全鏈路Perfetto 測試體系實戰(zhàn)指南單元測試、集成測試、Diff 測試與 CI 全鏈路 Perfetto 因構建配置與嵌入目標獨立構建、Android in可觀測性后端開發(fā)工具前端數(shù)據(jù)可視化上一篇LightTable快捷鍵大全提升編碼速度的50個必備快捷鍵下一篇Minerva模型可視化工具使用教程從特征提取到熱力圖分析創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 SparkyFitness 全棧測試體系實戰(zhàn)指南：Jest、pytest 與路徑感知的 CI 測試流水線
后端前端移動開發(fā)【免費下載鏈接】SparkyFitnessSparkyFitness: Built for Families. Powered by AI. Track food, fitness, water, and health — together.項目地址https://gitcode.com/gh_mirrors/sp/SparkyFitness點擊查看免費下載導讀SparkyFitness 是一個橫跨前端Vite React、后端Node.js Express、移動端React Native Expo與 Garmin 微服務Python的多倉組件項目。本文以倉庫開發(fā)者文檔 docs/src/developer/testing.md 為核心骨架結合 .github/workflows/ci-tests.yml 及各子項目的真實配置與測試用例系統(tǒng)講解四個組件的本地測試命令、統(tǒng)一的 Mock 編寫規(guī)范、基于路徑變更檢測的 CI 流水線以及覆蓋率報告的處理方式。讀完本文你將掌握如何在本地快速跑通任意組件的測試、如何按倉庫既有模式編寫可維護的前端組件測試以及理解 CI 中只測受影響組件和數(shù)據(jù)庫遷移雙重校驗的設計思路。一、測試技術?？傆[SparkyFitness 的測試體系按組件選用兩套主流工具鏈組件技術棧測試框架關鍵配置位置SparkyFitnessFrontendVite React TypeScriptJestts-jest jsdompackage.json、setupTests.tsSparkyFitnessServerNode.js Express TypeScriptVitestpackage.json、vitest.config.tsSparkyFitnessMobileReact Native ExpoJestjest-expo presetpackage.json、jest.setup.jsSparkyFitnessGarminPython 微服務pytest unittest 兼容requirements.txt、tests/test_daily_calories.py從源碼結構看這種前端/移動端用 Jest、后端用 Vitest、Python 服務用 pytest的分工既保持了各組件生態(tài)內最成熟的測試實踐如前端 jest-dom 匹配器、后端 Vitest 的 ESM 原生支持又讓每個 CI Job 擁有獨立的依賴與運行環(huán)境互不干擾。二、本地運行測試四個組件的命令清單各組件腳本定義在其自身的 package.json或 Garmin 的依賴清單中以下命令與文檔一致并標注了每個命令在配置文件中的真實出處# Frontend (Vite React) —— 對應 SparkyFitnessFrontend/package.json cd SparkyFitnessFrontend pnpm test # Run tests in watch mode對應 test: jest pnpm test:ci # Run tests once with coverage對應 test:ci: jest --ci --coverage --maxWorkers2 # Backend (Node.js Express) —— 對應 SparkyFitnessServer/package.json cd SparkyFitnessServer pnpm test # Run tests in watch mode實際為 test: vitest runtest:watch: vitest pnpm test:ci # Run tests once with coveragetest:ci: vitest run --coverage --reporterverbose # Mobile (React Native Expo) —— 對應 SparkyFitnessMobile/package.json cd SparkyFitnessMobile npm run test:run # Run tests oncetest:run: jest npm run test:ci # Run tests once with coveragetest:ci: jest --ci --coverage --maxWorkers2 # Garmin Microservice (Python) cd SparkyFitnessGarmin pytest --cov. --cov-reporthtml幾點值得注意的細節(jié)CI 模式的共性三個 JS/TS 組件在test:ci中都使用了--ci標志前端與移動端還帶--maxWorkers2限制并行 Worker 數(shù)避免 CI 資源爭搶后端則改用--reporterverbose輸出更詳細的失敗信息。Watch 模式的差異前端與移動端的pnpm test/npm run test默認進入 Jest watch 模式后端文檔中寫的pnpm test實際執(zhí)行vitest run單次運行如需監(jiān)聽則使用pnpm test:watch即vitest。從 SparkyFitnessServer/package.json 的 scripts 定義可以看出這一差別。驗證鏈CI 在跑測試前還會執(zhí)行各組的validate腳本——前端為typecheck lint format:check knip后端為typecheck lint format:check移動端則在 i18n 與肌肉圖生成校驗之外疊加 typecheck、lint、knip 與原生本地化檢查。測試與靜態(tài)檢查在流水線中是兩道并行的質量閘門。三、CI 工作流路徑感知的按需測試倉庫的 CI 流水線定義在 .github/workflows/ci-tests.yml在 pull request 以及推送到main分支時觸發(fā)。與每次全量跑所有測試的樸素做法不同該流水線借助 dorny/paths-filter 做路徑變更檢測只對實際改動的組件運行測試從而顯著壓縮 PR 的等待時間。觸發(fā)條件與組件映射表工作流最外層通過paths限定觸發(fā)范圍——只有四個組件目錄、移動端/iOS 相關文件或工作流自身發(fā)生變化時才會啟動組件觸發(fā)路徑包管理器測試命令對應 CI JobFrontendSparkyFitnessFrontend/**pnpmpnpm run test:cifrontend-testsMobileSparkyFitnessMobile/**npmnpm run test:cimobile-testsServerSparkyFitnessServer/**pnpmpnpm run test:ciserver-testsGarminSparkyFitnessGarmin/**pippytestgarmin-tests注Mobile 一列文檔標注 npm但實際工作流中移動端 Job 仍使用pnpm install --frozen-lockfile安裝依賴測試命令則為pnpm run test:ci見 ci-tests.yml 的mobile-tests步驟與 SparkyFitnessMobile/package.json 中定義的腳本一致此處以工作流實際內容為準。兩階段執(zhí)行模型流水線由第一個changesJob 和四個/六個后續(xù)測試 Job 組成測試 Job 均通過needs: changes與if: needs.changes.outputs.component true做條件門控changesDetect Changesactions/checkoutv4檢出代碼后用dorny/paths-filterv2按五組過濾器frontend、mobile、server、garmin、migrations計算哪些組件有改動并將結果以 job outputs 形式暴露。按需測試 Jobfrontend-tests、mobile-tests、server-tests、garmin-tests各自只在自己的目錄working-directory下執(zhí)行migration-check與migration-upgrade-check則僅在遷移相關文件變化時啟動詳見下文。各測試 Job 的通用流程可概括為actions/checkoutv4→pnpm/action-setupv4安裝 pnpm →actions/setup-nodev4配置指定 Node 版本并緩存 pnpm 依賴cache-dependency-path: pnpm-lock.yaml→pnpm install --frozen-lockfile鎖定版本安裝 → 運行validate類型檢查、Lint、格式化→ 運行test:ci并輸出覆蓋率 →actions/upload-artifactv4上傳 coverage 目錄retention-days: 7保留 7 天。各 Job 的獨有細節(jié)Node 版本前端、后端、遷移 Job 使用 Node 24移動端使用 Node 20見各 Job 的setup-node步驟與各自依賴的運行時要求匹配。后端測試的密鑰處理server-testsJob 環(huán)境特意不設置SPARKY_FITNESS_API_ENCRYPTION_KEY與BETTER_AUTH_SECRET而是由 vitest.config.ts 在每次運行時用crypto.randomBytes生成隨機回退值。這樣倉庫中不落任何密鑰字面量避免 GitGuardian 等密鑰掃描器在每次 push 時報警。后端 Job 還設置了SKIP_RLS_MATRIX: 1因為該 Job 沒有數(shù)據(jù)庫RLS 權限矩陣測試會被跳過留待專門的遷移 Job 在真實 Postgres 上驗證。Garmin Job使用actions/setup-pythonv5Python 3.12 pip 緩存先pip install -r requirements.txt再補裝pytest pytest-cov執(zhí)行pytest --cov. --cov-reportxml --cov-reporthtml當目錄中不存在測試時打印提示跳過且該步驟配置了continue-on-error: true覆蓋率上傳仍通過if: always()保證執(zhí)行。數(shù)據(jù)庫遷移的雙重校驗這是流水線中值得單獨講透的部分。migration-checkFresh-install Migrations與migration-upgrade-checkUpgrade-path Migrations共享同一個migrations過濾條件覆蓋路徑包括SparkyFitnessServer/db/migrations/**、rls_policies.sql、grantPermissions.ts、dbMigrations.ts、applyRlsPolicies.ts、initializeDatabase.ts及相關集成測試文件。兩個 Job 都通過services拉起postgres:18.3-alpine容器POSTGRES_DB: sparky_test健康檢查pg_isreadymigration-check全新安裝路徑在空庫上并行啟動兩個pnpm run test:migrations進程tests/migrate.script.ts入口驗證并發(fā)初始化時數(shù)據(jù)庫鎖與冪等機制的正確性隨后依次執(zhí)行 RLS 權限矩陣、Strava 清理、OIDC 提供方、Better Auth schema對應歷史上 #2469/#2470 認證中斷事故的回歸測試、登錄限流、provider 同步聲明等集成測試并固定SPARKY_FITNESS_FRONTEND_URLhttp://localhost:3004以保證 Better Auth 實例構建方式一致。migration-upgrade-check升級路徑fetch-depth: 0拉取完整歷史先用git checkout ${BASE_SHA}把基礎分支的 SQL 遷移文件換入并跑一遍test:migrations再換回 PR 的遷移文件跑第二遍。由于schema_migrations表在兩次運行間保留第二遍只會應用新增遷移——恰好模擬存量部署平滑升級的真實場景專門捕獲那些只在已填充數(shù)據(jù)的 schema 上才會暴露的遷移問題。四、測試文件布局文檔給出了各組件測試目錄的組織方式結合倉庫實際文件結構可進一步確認SparkyFitnessFrontend/ src/tests/ setupTests.ts # 全局測試初始化jest-dom、polyfills test-utils.tsx # renderWithClient 測試渲染輔助 stubs/ # betterAuth、react-markdown 等第三方模塊樁 components/ # 組件測試與組件領域一一對應 MealBuilder.test.tsx MealManagement.test.tsx MealPlanCalendar.test.tsx SparkyFitnessServer/ tests/ # 后端單元與集成測試*.test.ts被 vitest include 捕獲 migrate.script.ts # 數(shù)據(jù)庫遷移執(zhí)行腳本test:migrations 入口 SparkyFitnessMobile/ __tests__/ components/ # 移動端組件測試 hooks/ # 自定義 Hook 測試 services/ # 服務層測試 screens/ # 屏幕級測試 localization/ # i18n 本地化測試從源碼看前端測試集中在src/tests/而非與組件文件同目錄后端則統(tǒng)一放在tests/下由 vitest.config.ts 的include: [**/tests/**/*.test.ts]收集移動端 Jest 配置還通過testPathIgnorePatterns排除了__tests__/helpers/、__tests__/hooks/queryTestUtils.ts等輔助文件避免輔助代碼被誤判為測試。五、編寫前端測試統(tǒng)一的 Mock 模式文檔強調所有前端組件測試遵循一致的 Mock 策略倉庫中最具代表性的例子是 MealBuilder.test.tsx該文件中對waitFor/renderWithClient/initialFoods的組合使用共出現(xiàn) 45 處是前端測試密集區(qū)的典型樣本。標準流程如下// 1. Mock i18n —— 返回回退字符串或翻譯 key jest.mock(react-i18next, () ({ useTranslation: () ({ t: (key: string, defaultValueOrOpts?: string | Recordstring, unknown) { if (typeof defaultValueOrOpts string) return defaultValueOrOpts; if (defaultValueOrOpts typeof defaultValueOrOpts object defaultValue in defaultValueOrOpts) { return defaultValueOrOpts.defaultValue as string; } return key; }, }), })); // 2. Mock contexts jest.mock(/contexts/ActiveUserContext, () ({ useActiveUser: () ({ activeUserId: test-user-id }), })); jest.mock(/contexts/PreferencesContext, () ({ usePreferences: () ({ loggingLevel: debug, itemDisplayLimit: 100 }), })); // 3. Mock toast jest.mock(/hooks/use-toast, () ({ toast: jest.fn() })); // 4. Mock logging jest.mock(/utils/logging, () ({ debug: jest.fn(), info: jest.fn(), warn: jest.fn(), error: jest.fn(), })); // 5. Mock services with trackable fns —— 用可斷言的 mock 函數(shù)包一層便于后續(xù)斷言調用 const mockGetMeals jest.fn(); jest.mock(/services/mealService, () ({ getMeals: (...args: unknown[]) mockGetMeals(...args), }));倉庫真實測試中的進階變體對照 MealBuilder.test.tsx 的開頭部分可以看到文檔模式的落地細節(jié)i18n mock 補全了initReactI18next除useTranslation外還導出了{ type: 3rdParty, init: () {} }避免組件初始化 i18n 實例時報錯。Context mock 攜帶業(yè)務默認值PreferencesContext的 mock 額外返回nutrientDisplayPreferences含view_group: quick_info與可見營養(yǎng)項數(shù)組、energyUnit: kcal與convertEnergy說明 mock 需覆蓋被測組件實際讀取的全部字段。API 服務按模塊整體 mock如jest.mock(/api/Foods/meals, ...)同時提供createMeal、updateMeal、getMealById三個可跟蹤函數(shù)。復雜子組件 stub 化FoodUnitSelector、FoodSearchDialog等子組件被替換為返回帶data-testid的簡單 div將被測組件與子組件實現(xiàn)徹底隔離。beforeEach(() jest.clearAllMocks())保證用例之間互不污染。約定與測試輔助文檔列出的約定在倉庫中得到一一印證測試文件與其組件領域同放于src/tests/components/按*.test.tsx命名使用testing-library/react進行渲染與斷言test-utils.tsx 提供了renderWithClient輔助內部創(chuàng)建retry: false的QueryClient并包裹QueryClientProvider同時掛載 Query/MutationCache 的全局錯誤 toast 處理用waitFor等待異步操作如await waitFor(() expect(screen.getByLabelText(Total Servings)).toBeInTheDocument())等待 API 調用后的 UI 狀態(tài)更新通過initialFoods之類的 props 直接注入數(shù)據(jù)避免依賴交互型子組件MealBuilder即以initialFoods{sampleFoods}注入樣本食物數(shù)據(jù)。六、移動端測試環(huán)境jest-expo 與全局樁移動端測試的復雜度主要來自大量原生模塊。其 Jest 配置SparkyFitnessMobile/package.json 的jest字段使用jest-expopreset 與 jsdom 環(huán)境并通過一份數(shù)百行的 jest.setup.js 集中樁掉無法在 Node 中運行的原生能力標準庫 polyfillTextEncoder/TextDecoderExpo winter 運行時按需安裝 whatwg-url 需要它們本地化與系統(tǒng) APIexpo-localization固定返回en-USexpo-application/expo-constants提供固定版本號健康數(shù)據(jù)橋kingstinct/react-native-healthkit的讀寫與授權 API 全部 mock寫回保存返回帶uuid的樣本對象確保 UUID 跟蹤斷言真實有效react-native-health-connect的權限、讀取、聚合 API 亦全部樁化動畫與手勢react-native-reanimated、react-native-gesture-handler、react-native-keyboard-controller提供鏈式可調用的樁實現(xiàn)保證拖拽排序、手勢等交互代碼在單元測試中可安全執(zhí)行第三方渲染庫victory-native、shopify/react-native-skia、react-native-maps、gorhom/bottom-sheet渲染為帶testID的 View供斷言畫了什么i18n 生產(chǎn)實例文件末尾加載真實的src/localization/i18n并以initImmediate: false同步初始化讓被隔離渲染的組件也能解析英文默認文案而非返回原始 key。同時moduleNameMapper將workspace/shared指向../shared/src/index.ts跨包共享代碼直接在測試中解析 TS 源碼并通過精心編寫的transformIgnorePatterns白名單讓 react-native、expo、react-navigation、workspace/shared、zod、better-auth 等 ESM 包通過 babel 轉換。七、后端測試Vitest 與運行時密鑰策略后端使用 Vitest 且采用globals: true測試文件中可直接使用 describe/it/expect環(huán)境為 Node。兩個值得關注的設計跨包共享代碼解析resolve.alias將workspace/shared指向../shared/src與前端、移動端的 moduleNameMapper 策略一致共享包源碼被直接納入各組件測試。隨機密鑰回退vitest.config.ts測試進程需要SPARKY_FITNESS_API_ENCRYPTION_KEY32 字節(jié) hex與BETTER_AUTH_SECRETbase64配置在讀取倉庫根.env后若缺失則用crypto.randomBytes生成每次運行不同的隨機值注入test.env。因為這些值只在進程內用于加解密與 cookie 簽名不持久化、不跨運行復用隨機生成完全安全同時保證倉庫內沒有任何密鑰字面量——這正是不把秘密寫進代碼的工程實踐在測試層的體現(xiàn)。后端測試腳本一覽SparkyFitnessServer/package.jsontest: vitest run, // 單次運行 test:watch: vitest, // 監(jiān)聽模式 test:coverage: vitest run --coverage, test:ci: vitest run --coverage --reporterverbose, test:migrations: tsx tests/migrate.script.tstest:migrations專供 CI 的遷移 Job 調用配合tests/migrate.script.ts與 Postgres 服務容器完成空庫初始化與升級路徑驗證。八、Garmin 微服務測試pytestGarmin 微服務Python使用 pytest 并帶覆蓋率輸出。倉庫中的 tests/test_daily_calories.py 是典型樣例以unittest.TestCase組織用例通過sys.path.insert將父目錄加入模塊搜索路徑后直接導入service.py的業(yè)務函數(shù)。測試覆蓋了規(guī)范字段解析activeKilocalories/bmrKilocalories/totalKilocalories正確映射為active_calories/bmr_calories/total_calories浮點值別名回退activeCalories/bmrCalories/totalCalories等已知別名在規(guī)范字段缺失時生效且字符串數(shù)字可被正確轉換邊界值保留合法的0剔除None、inf與 not-a-number 等缺失或非法值。本地運行方式pytest --cov. --cov-reporthtmlCI 中則執(zhí)行pytest --cov. --cov-reportxml --cov-reporthtml并將htmlcov/作為構建產(chǎn)物上傳。九、覆蓋率報告與產(chǎn)物管理運行test:ci后各組件會在自身目錄下生成coverage/前端與移動端Garmin 為htmlcov/。CI 中這些目錄通過actions/upload-artifactv4上傳為構建產(chǎn)物retention-days: 7表示保留 7 天后自動清理Job上傳產(chǎn)物名上傳路徑保留天數(shù)frontend-testsfrontend-coverageSparkyFitnessFrontend/coverage/7mobile-testsmobile-coverageSparkyFitnessMobile/coverage/7server-testsserver-coverageSparkyFitnessServer/coverage/7garmin-testsgarmin-coverageSparkyFitnessGarmin/htmlcov/7上傳步驟均使用if: always()即使測試失敗也會保留覆蓋率產(chǎn)物便于事后在 GitHub Actions 的 Artifacts 中下載分析。本地查看覆蓋率時可直接打開 HTML 報告前端/移動端coverage/lcov-report/index.htmlGarminhtmlcov/index.html逐文件瀏覽未覆蓋分支。十、編寫測試的通用建議綜合文檔約定與倉庫實踐可沉淀出以下可復用的編寫準則Mock 一切外部依賴只測被測單元i18n、Context、toast、日志、API 服務、復雜子組件逐一樁化對需要斷言的服務調用用可跟蹤的jest.fn包裹并在測試內斷言調用參數(shù)與次數(shù)。用真實輔助函數(shù)包裹 Provider如renderWithClient統(tǒng)一注入 QueryClient關閉重試避免每個測試重復樣板代碼。異步一律waitForAPI 調用、狀態(tài)更新等異步 UI 斷言放在waitFor中配合screen查詢器與 jest-dom 匹配器toBeInTheDocument、toBeEnabled書寫。通過 props 注入數(shù)據(jù)優(yōu)先用initialFoods這類輸入屬性驅動組件而不是依賴子組件交互來間接準備數(shù)據(jù)。保持 CI 與本地一致本地先跑validatetypecheck/lint/format再跑test:ci與 CI 的檢查順序保持一致避免本地綠、CI 紅。涉及數(shù)據(jù)庫的改動務必關注遷移 Job任何db/migrations/**、RLS 策略或遷移運行器文件的改動都會觸發(fā)兩個需要真實 Postgres 的集成驗證本地可借助 docker-compose 中的數(shù)據(jù)庫服務先行演練。延伸閱讀開發(fā)者文檔目錄架構architecture.md、數(shù)據(jù)庫database.md、權限層級database-security-tiers.md、troubleshooting.md 等配套文檔。前端全局測試初始化jsdom polyfillsmatchMedia、ResizeObserver、PointerEvent與 react-leaflet/leaflet 樁。移動端全局測試初始化Expo 生態(tài)原生模塊的完整 mock 清單。后端測試運行器配置隨機密鑰回退與workspace/shared別名。Garmin 測試樣例Python 側單元測試的編寫范式。贊分享后端前端移動開發(fā)【免費下載鏈接】SparkyFitnessSparkyFitness: Built for Families. Powered by AI. Track food, fitness, water, and health — together.項目地址https://gitcode.com/gh_mirrors/sp/SparkyFitness點擊查看免費下載相關推薦FastLED 的 CI 測試套件指南ci/tests pytest 測試體系全解析FastLED 的 CI 測試套件指南ci/tests pytest 測試體系全解析 FastLED 倉庫在 ci/tests https://link.gi嵌入式物聯(lián)網(wǎng)硬件開發(fā)驅動開發(fā) Transformers 測試指南從 CI 流水線到測試編寫實戰(zhàn) Transformers 測試指南從 CI 流水線到測試編寫實戰(zhàn) 本文是 Transformers 倉庫官方日語版《Testing》文檔的深度解讀人工智能大模型深度學習NLP預訓練微調模型推理服務Perfetto 測試體系實戰(zhàn)指南單元測試、集成測試、Diff 測試與 CI 全鏈路Perfetto 測試體系實戰(zhàn)指南單元測試、集成測試、Diff 測試與 CI 全鏈路 Perfetto 因構建配置與嵌入目標獨立構建、Android in可觀測性后端開發(fā)工具前端數(shù)據(jù)可視化上一篇LightTable快捷鍵大全提升編碼速度的50個必備快捷鍵下一篇Minerva模型可視化工具使用教程從特征提取到熱力圖分析創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考