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