Testing & Bảo mật cơ bản
Mục tiêu
Yêu cầu AI viết test cho app. Kiểm tra hiệu năng, SEO cơ bản, và bảo mật API key.
Sau bài này, bạn sẽ:
- ✅ Hiểu testing là gì và tại sao cần test trước khi launch
- ✅ Biết cách prompt AI viết test case cho app
- ✅ Nắm checklist bảo mật cơ bản cho vibe coder
- ✅ Dùng Lighthouse kiểm tra hiệu năng và SEO
Nội dung chính
7.1 — Testing: “Kiểm tra trước khi giao hàng”
TESTING LÀ GÌ?
Bạn xây nhà xong → KHÔNG PHẢI giao nhà liền.
Phải kiểm tra: nước chảy chưa? điện có không? cửa khoá được không?
Code cũng vậy:
- Nút Đăng nhập có hoạt động không?
- Thêm sản phẩm có lưu vào database không?
- Xoá task có xoá thật không?
- Nếu internet chậm, app có crash không?
Mẹo: Bạn không cần hiểu code test. Chỉ cần MÔ TẢ kịch bản bằng tiếng Việt, AI sẽ viết code test cho bạn. Việc của bạn là nghĩ ra “chuyện gì có thể sai?” — AI lo phần code.
Prompt yêu cầu AI viết test (chi tiết):
Viết test cho app FocusFlow theo các kịch bản sau.
Setup:
- Dùng Vitest + React Testing Library
- Tạo file test cùng thư mục với component (ví dụ: Login.test.jsx)
- Mock Supabase client (không gọi database thật khi test)
Kịch bản đăng nhập:
1. Đăng nhập với email đúng + mật khẩu đúng
→ Chuyển về trang chủ, hiển thị tên user
2. Đăng nhập với mật khẩu sai
→ Hiện thông báo "Sai mật khẩu" màu đỏ
→ KHÔNG chuyển trang
3. Đăng nhập với email chưa đăng ký
→ Hiện thông báo "Email chưa đăng ký"
4. Bấm đăng nhập khi chưa nhập gì
→ Hiện thông báo "Vui lòng nhập email và mật khẩu"
Kịch bản quản lý task:
5. Thêm task mới → task xuất hiện trong danh sách
6. Xóa task → task biến mất, danh sách cập nhật
7. Đánh dấu hoàn thành → task hiện gạch ngang
8. Tải lại trang → dữ liệu vẫn còn (mock API trả đúng data)
Kịch bản edge case:
9. Nhập task với tên rỗng → hiện lỗi validation
10. Nhập task với tên > 200 ký tự → hiện cảnh báo
Mỗi test có comment giải thích bằng tiếng Việt.
Prompt nâng cao — Test tự động chạy trước mỗi commit:
Setup CI/CD đơn giản cho project:
1. Thêm script test vào package.json:
"test": "vitest run"
"test:watch": "vitest"
2. Tạo file .github/workflows/test.yml:
- Chạy test tự động mỗi khi push lên GitHub
- Nếu test fail → không cho merge PR
- Gửi notification kết quả
3. Thêm pre-commit hook (dùng husky):
- Chạy test trước mỗi commit
- Nếu test fail → không cho commit
Giải thích từng bước đơn giản, tôi chưa biết CI/CD.
7.2 — Bảo mật cơ bản: Checklist
┌──────────────────────────────────────────────────────────────┐
│ CHECKLIST BẢO MẬT CHO VIBE CODER │
│ │
│ □ API key, database password ĐỂ TRONG .env │
│ KHÔNG hard-code trong file code │
│ │
│ □ File .env ĐÃ THÊM VÀO .gitignore │
│ (không push lên GitHub) │
│ │
│ □ Supabase RLS ĐÃ BẬT cho mọi bảng │
│ (user chỉ thấy dữ liệu của mình) │
│ │
│ □ KHÔNG lưu mật khẩu dạng text thường │
│ (Supabase Auth tự hash, không cần lo) │
│ │
│ □ HTTPS đã bật (Vercel tự bật, không cần lo) │
│ │
│ □ Form nhập liệu có validation (kiểm tra dữ liệu hợp lệ) │
│ │
└──────────────────────────────────────────────────────────────┘
Giải thích chi tiết từng item:
API key trong .env: API key giống chìa khoá nhà bạn. Nếu để trong code → push lên GitHub → ai cũng thấy → họ dùng key bạn → bạn bị tính phí (hoặc tệ hơn, họ truy cập database bạn).
Supabase RLS (Row Level Security): Không bật RLS = ai có URL database cũng đọc/sửa/xóa được TẤT CẢ dữ liệu. Bật RLS = mỗi user chỉ thấy data của mình. Cực kỳ quan trọng.
KHÔNG CÓ RLS: CÓ RLS:
────────────── ────────
User A gọi API → thấy data của B, C User A gọi API → chỉ thấy data của A
Hacker gọi API → thấy TẤT CẢ data Hacker gọi API → chỉ thấy data của hacker
→ LỘ DỮ LIỆU TOÀN BỘ → An toàn
Mẹo: Kiểm tra nhanh .env có trong .gitignore chưa: mở terminal, chạy
cat .gitignore | grep .env. Nếu không thấy.env→ NGUY HIỂM, thêm ngay. Nếu đã lỡ push .env lên GitHub, API key đã bị lộ — phải tạo key MỚI ngay lập tức.
Prompt kiểm tra bảo mật (chi tiết):
Hãy review toàn bộ @codebase và kiểm tra bảo mật:
1. API KEY SCAN:
- Tìm tất cả API key, password, secret bị hard-code trong code
- Kiểm tra có file nào chứa chuỗi giống key không
(dài > 20 ký tự, chứa chữ + số random)
- Nếu tìm thấy → chuyển vào .env, thay bằng process.env.VITE_xxx
2. GITIGNORE CHECK:
- File .env có trong .gitignore chưa?
- .env.local, .env.production có trong .gitignore chưa?
- Có file nhạy cảm nào khác cần ignore? (credentials.json, serviceAccount.json...)
3. SUPABASE RLS:
- Liệt kê TẤT CẢ bảng trong database
- Kiểm tra RLS đã bật cho mỗi bảng chưa
- Đề xuất RLS policy cho mỗi bảng (user chỉ CRUD data của mình)
4. INPUT VALIDATION:
- Tìm tất cả form / input trong app
- Kiểm tra có validation không (email đúng format, password đủ mạnh)
- Có sanitize input không (chống XSS — mã độc trong text)
5. AUTHENTICATION:
- Route nào cần đăng nhập mới truy cập được?
- Có route nào quên protect không? (user chưa login vẫn vào được)
Trả lời dạng checklist: ✅ OK hoặc ❌ Cần sửa + hướng dẫn sửa.
7.3 — Hiệu năng: Lighthouse
Cách kiểm tra tốc độ app:
1. Mở app trên Chrome
2. F12 → Tab "Lighthouse"
3. Bấm "Analyze page load"
4. Xem điểm: Performance, Accessibility, Best Practices, SEO
Mục tiêu:
- Performance: > 80
- Accessibility: > 90
- Best Practices: > 80
- SEO: > 80
Nếu điểm thấp, copy kết quả cho AI:
"Lighthouse report cho app tôi: Performance 65, SEO 70.
Hãy đề xuất cách cải thiện, ưu tiên những thay đổi dễ nhất trước."
Các cải thiện phổ biến nhất (dễ làm, tác động lớn):
| Vấn đề | Cách sửa | Tác động |
|---|---|---|
| Ảnh quá nặng | Nén ảnh (tinypng.com) + lazy load | Performance +10-20 |
| Không có meta tags | Thêm title, description, og:image | SEO +15-25 |
| Font load chậm | Thêm font-display: swap | Performance +5-10 |
| Thiếu alt text cho ảnh | Thêm alt mô tả cho mỗi img | Accessibility +10-15 |
| Contrast thấp | Đậm màu chữ hoặc sáng nền | Accessibility +5-10 |
Mẹo: Chạy Lighthouse ở chế độ Incognito (Ctrl+Shift+N). Extensions trình duyệt có thể làm giảm điểm Performance. Chạy ở Incognito = không có extensions = kết quả chính xác hơn.
Lỗi thường gặp
Vấn đề: Test fail với lỗi “Cannot find module” — không tìm thấy Vitest.
→ Giải pháp: Cần cài Vitest trước: npm install -D vitest @testing-library/react @testing-library/jest-dom. Thêm config vào vite.config.js: test: { environment: 'jsdom', globals: true }. Prompt AI: “Setup Vitest cho project React + Vite của tôi từ đầu.”
Vấn đề: API key đã lỡ push lên GitHub — bị lộ.
→ Giải pháp: (1) Vào trang web API đó → tạo key MỚI ngay lập tức. (2) Revoke (huỷ) key cũ. (3) Cập nhật key mới vào .env. (4) Thêm .env vào .gitignore. (5) Xóa .env khỏi git history: git rm --cached .env → commit. Lưu ý: key cũ KHÔNG an toàn nữa dù bạn xóa file — vì lịch sử git vẫn lưu.
Vấn đề: Test pass trên máy mình nhưng fail trên GitHub Actions.
→ Giải pháp: Thường do biến môi trường thiếu trên CI. Kiểm tra: (1) GitHub repo → Settings → Secrets → đã thêm biến chưa? (2) File workflow có env: section đúng không? (3) Test có phụ thuộc vào database thật không? (nên mock).
Vấn đề: Lighthouse cho điểm Performance rất thấp (<50).
→ Giải pháp: 3 quick wins: (1) Ảnh — nén tất cả ảnh qua tinypng.com, thêm loading="lazy" cho ảnh dưới fold. (2) Bundle — prompt AI: “Analyze bundle size và đề xuất cách giảm. Lazy load các trang không phải trang chính.” (3) Font — chỉ load weight cần dùng (400, 600, 700), không load cả bộ.
Vấn đề: Supabase RLS bật rồi nhưng data không hiển thị — query trả về mảng rỗng. → Giải pháp: RLS policy có thể quá chặt. Kiểm tra: (1) Vào Supabase Dashboard → Table Editor → xem data có tồn tại không. (2) Authentication → xem user đang login có đúng id không. (3) Policy → xem điều kiện có khớp không. Prompt AI: “RLS đã bật cho bảng [tên] nhưng query trả về rỗng. Đây là policy hiện tại: [paste policy]. Kiểm tra có đúng không.”
Bài tập thực hành
Nhiệm vụ:
Các bước thực hiện:
- Yêu cầu AI viết 5+ test cases cho tính năng quan trọng nhất trong đồ án (~10 phút)
- Chạy test:
npm run test— sửa nếu fail (~5 phút)- Chạy checklist bảo mật (dùng prompt ở mục 7.2) (~5 phút)
- Chạy Lighthouse — ghi lại điểm 4 mục (~3 phút)
- Cải thiện nếu điểm nào < 80 (~5 phút)
- Commit (~2 phút)
Tiêu chí hoàn thành:
- Có ít nhất 5 test cases chạy pass
- Checklist bảo mật: tất cả item đều check (đặc biệt .env và RLS)
- Lighthouse: tất cả 4 mục >= 80
- Đã commit lên GitHub
Gợi ý nếu bị stuck: Nếu viết test quá khó, bắt đầu với test đơn giản nhất: “Test component [tên] render được mà không crash.” Đây gọi là “smoke test” — chỉ kiểm tra app không nổ. Sau đó mới thêm test cho logic phức tạp hơn.
Thời gian: 30 phút Deliverable: Screenshot kết quả test + Screenshot Lighthouse report + commit
Kiểm tra kiến thức
1. Supabase RLS (Row Level Security) bảo vệ app bằng cách nào?
2. Nếu đã lỡ push file .env lên GitHub, bước đầu tiên cần làm là gì?
3. Lighthouse dùng để kiểm tra điều gì?
4. Khi viết test, vibe coder cần làm gì?
5. Cách nhanh nhất để cải thiện điểm Performance trên Lighthouse là gì?