Android Emulator

今天要先以詞彙題為架構建立起APP的雛型，然而反覆將安裝包丟到手機下載業太過麻煩，所以透過安裝Android Emulator就可以在電腦模擬手機程式的運行。

一、程式碼架構

gsat-english-tutor-APP 裡實際的模組劃分——唯一的核心測試接縫是 practice-domain，其他都是圍繞它的薄 adapter。

src/domain/
practice-domain 純函式 驗證／選題／計分，零外部依賴，19 個單元測試

src/db/
Postgres 直連 adapter migration runner + 整合測試共用，繞過 RLS（開發者工具用途）

src/web/
UI + Supabase adapter auth／practice 畫面，透過 anon key + RLS 存取

scripts/
開發者工具 migration 套用、批次生成（驗證＋寫入，不含 AI 呼叫）

supabase/migrations/
Schema 原始碼 冪等、可在乾淨專案重跑

測試策略

透過SPEC制定的三層策略，讓AI自我審查自己寫出來的內容真的是對的。

單元測試-19個

practice-domain 純函式，TDD red-green，不碰資料庫或裝置。

這部分測的是「純邏輯」的部分,例如:「答對加1分、答錯扣1分,對不對」「選題時真的會挑分數最低的字嗎」。這些邏輯完全不需要碰真的資料庫或手機,寫一段小程式碼直接呼叫函式、檢查回傳結果對不對就好,跑起來很快,可以常常重跑確認沒改壞東西。

整合測試-1個

Supabase schema 寫入＋讀回，真的連線，會自動 skip 若無 .env。

這部分測的是「這支程式真的連得上Supabase資料庫嗎、寫進去的資料格式對不對」。這個沒辦法只測邏輯,一定要真的連線出去,所以叫「整合」測試——如果你電腦上沒設定好連線資訊(.env),這個測試會自動跳過,不會讓整包測試失敗。

模擬器手動驗證-10次

Auth／practice 流程——anon key 建立的測試帳號無法自動清理，改用真實跑一輪＋獨立 SQL 核對。

測的是「App整個裝起來、真人操作一遍,結果對不對」,例如登入、拿到題目、答題、看到檢討畫面。這個沒辦法自動化,因為每次登入/註冊都會在Supabase裡建立一個真的測試帳號,而我們沒有權限自動刪除這些帳號——如果寫成自動化測試,每次執行都會多留一個用不到的帳號,永遠清不掉。所以改成:我自己操作一次模擬器,同時另外用SQL指令去資料庫裡核對「資料真的有寫進去、內容是對的」,不是只看App畫面顯示什麼就相信什麼。

三、初版發布

發布v0.1.0-pilot — 第一個能實際安裝、跑完整核心流程的版本。用keystore 簽章，透過 private GitHub Release 散布，開發者在一台沒裝過的真實 Android 手機上下載安裝——跳出「不明來源」警告、點「仍要安裝」成功，核心流程（登入→出題→作答→檢討）全部測試成功。

(之後會再改進UI)