Từ Zero đến Principal Frontend Engineer (P7: Chiến lược Testing Frontend - Từ Unit Test đến E2E)

Phần 1: Tại Sao Testing Là "Non-Negotiable"?

1.1 Hậu quả của Poor Testing

• Case study: Một công ty mất $2.4 triệu do bug checkout không được phát hiện vì thiếu integration test.
• Số liệu: 40% bug frontend đến từ state management sai (Redux, Context API) – có thể ngăn chặn bằng unit test.

1.2 Tư Duy Testing

• Testing như documentation: Mỗi test case phải mô tả business requirement.
• Cost of change: Chi phí sửa bug tăng gấp 10 lần nếu phát hiện muộn (theo IBM Systems Sciences Institute).

Phần 2: Chi Tiết Từng Tầng Testing Pyramid

2.1 Unit Testing: Nền Tảng Của Reliability

Công cụ tối ưu:

• Jest (cho React/Vue) hoặc Vitest (tốc độ cực nhanh với Vite).
• React Testing Library (khuyến khích test behavior thay vì implementation).

Ví dụ Phức Tạp: Test Custom Hook với Async Logic

// useAuthHook.js
export const useAuth = () => { const [user, setUser] = useState(null); const login = async (email, password) => { const response = await api.login(email, password); setUser(response.data.user); }; return { user, login };
}; // useAuthHook.test.js
test('login updates user state', async () => { jest.spyOn(api, 'login').mockResolvedValue({ data: { user: { id: 1, name: 'John' } } }); let hookResult; function TestComponent() { hookResult = useAuth(); return null; } render(<TestComponent />); await act(async () => { await hookResult.login('test@example.com', 'password'); }); expect(hookResult.user).toEqual({ id: 1, name: 'John' });
});

Best Practices:

• Mocking chuẩn: Sử dụng jest.mock cho module phức tạp (ví dụ: API calls).
• Coverage có mục tiêu: 100% cho core business logic, 70% cho UI components.

2.2 Integration Testing: Kịch Bản Thực Tế

Công cụ đề xuất:

• MSW (Mock Service Worker): Mock API cực mạnh, hỗ trợ GraphQL/REST.
• Testing Library render với Redux Provider.

Ví dụ: Test Form Submit với API Call và State Update

// LoginForm.test.js
import { setupServer } from 'msw/node';
import { rest } from 'msw'; const server = setupServer( rest.post('/api/login', (req, res, ctx) => { return res(ctx.json({ token: 'fake-token' })); })
); beforeAll(() => server.listen());
afterAll(() => server.close()); test('submits login form and stores token', async () => { const mockStore = configureMockStore(); const store = mockStore({}); render( <Provider store={store}> <LoginForm /> </Provider> ); fireEvent.change(screen.getByLabelText('Email'), { target: { value: 'test@example.com' } }); fireEvent.change(screen.getByLabelText('Password'), { target: { value: 'password' } }); fireEvent.click(screen.getByRole('button', { name: 'Login' })); await waitFor(() => { const actions = store.getActions(); expect(actions[0].type).toEqual('auth/loginSuccess'); expect(actions[0].payload).toEqual('fake-token'); });
});

Lỗi Thường Gặp:

• Quá nhiều mock: Dẫn đến test không giống production. Giải pháp: Dùng MSW để mock ở network level.
• Test quá rộng: Một test case kiểm tra cả UI + API + State. Nên tách thành nhiều test nhỏ.

2.3 E2E Testing: Tập Trung Vào Critical Paths

So Sánh Công Cụ:

Ví dụ Playwright Test cho Checkout Flow:

// checkout.spec.ts
import { test, expect } from '@playwright/test'; test('complete checkout as guest', async ({ page }) => { await page.goto('/products/1'); await page.click('text=Add to Cart'); await page.click('#cart-icon'); await page.fill('input[name="email"]', 'test@example.com'); await page.click('text=Proceed to Checkout'); await expect(page).toHaveURL('/checkout'); await page.click('text=Place Order'); await expect(page.locator('.order-confirmation')).toBeVisible();
});

Chiến Lược E2E Hiệu Quả:

• Chỉ test happy paths: Login, Checkout, Search.
• Dùng tagging: @smoke, @regression để phân loại test suite.
• Kết hợp với monitoring: Sentry để bắt lỗi production chưa được test.

Phần 3: Chiến Lược Duy Trì Test Suite

3.1 Tích Hợp Vào CI/CD

# GitHub Actions example
jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm install - run: npm run test:unit -- --coverage - run: npm run test:integration - run: npx playwright test - uses: actions/upload-artifact@v3 if: failure() with: name: playwright-report path: playwright-report/

3.2 Đo Lường Hiệu Quả

• Số liệu cần track:
  • Bug escape rate: Số bug lọt vào production / tổng bug.
  • Test flakiness: Tỉ lệ test fail không ổn định.
• Tool: Jest Sonar reporter, Cypress Dashboard.

Kết Luận

• Testing không phải để đạt coverage 100%, mà để giảm rủi ro business.
• Luôn đặt câu hỏi: "Nếu test này fail, có ảnh hưởng đến user không?".