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