Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:The testing strategy for the llama-leaks frontend is primarily focused on ensuring production stability through comprehensive error monitoring, maintaining code quality with static analysis, and building resilient components. Given the project's nature as an educational security awareness tool, the strategy prioritizes real-world monitoring and developer-time verification over a traditional, extensive unit or end-to-end test suite.
This approach is centered around three key pillars:
- Error and Performance Monitoring: Using Sentry to capture and analyze exceptions and performance data in production.
- Development-Time Verification: A dedicated testing component to validate the Sentry integration during development.
- Code Quality and Consistency: Employing ESLint for static code analysis to prevent common errors and enforce coding standards.
- Component-Level Resilience: Implementing robust error handling within components that fetch external data.
1. Error and Performance Monitoring with Sentry
The core of the production testing strategy is the integration of Sentry for real-time error tracking and performance monitoring. This allows the team to proactively identify, triage, and resolve issues that users encounter.
Sources: frontend/package.json:39-40
1.1. Sentry Integration Verification
To ensure the Sentry integration is functioning correctly, a dedicated React component, SentryTestButton, is available exclusively in the development environment. This component provides a simple UI for developers to trigger various types of Sentry events manually.
Sources: frontend/src/components/SentryTestButton.tsx, frontend/src/pages/Index.tsx:14-16, frontend/src/pages/Index.tsx:43-49
Sentry Test Functions
The SentryTestButton component includes methods to test different aspects of the Sentry SDK.
| Function Name | Description | Sentry Method Triggered (Implicit/Explicit) |
|---|---|---|
testError | Throws an uncaught error to test Sentry's global error handler. Adds a breadcrumb before throwing. | Sentry.captureException (by SDK) |
testCaptureException | Catches an error within a try...catch block and manually sends it to Sentry with additional context. | captureException |
testCaptureMessage | Sends a custom informational message to Sentry. | captureMessage |
testPerformance | Creates and completes a performance span to test Sentry's performance monitoring capabilities. | startSpan |
Sources: frontend/src/components/SentryTestButton.tsx:12-42
Test Event Flow
The following diagram illustrates the sequence of events when a developer uses the "Test Uncaught Error" button.
This diagram shows how an action in the SentryTestButton component results in an error being captured and sent to the Sentry platform.
Sources: frontend/src/components/SentryTestButton.tsx:13-16
1.2. Development Environment Integration
The SentryTestButton is conditionally and lazily loaded into the main Index page only when the application is running in a development environment. This prevents the test utility from being included in the production bundle, ensuring a clean and efficient build for end-users.
This flowchart depicts the logic for conditionally rendering the Sentry test component.
Sources: frontend/src/pages/Index.tsx:14-16, frontend/src/pages/Index.tsx:43-49
2. Static Code Analysis
The project enforces code quality and consistency through static analysis using ESLint. The configuration is set up for TypeScript, React hooks, and general JavaScript best practices.
Sources: frontend/package.json:7-9, frontend/package.json:69-77
2.1. Linting Toolchain
The following devDependencies in package.json constitute the project's linting and static analysis toolchain.
| Package | Purpose |
|---|---|
eslint | The core linting utility. |
@eslint/js | Provides recommended JavaScript rules. |
typescript-eslint | A tool that enables ESLint to lint TypeScript code. |
eslint-plugin-react-hooks | Enforces the Rules of Hooks in React components. |
eslint-plugin-react-refresh | Provides ESLint rules for React Refresh. |
Sources: frontend/package.json:69-77
2.2. Linting Script
A lint script is defined in package.json to allow developers to run the linter across the entire codebase easily.
"scripts": {
"dev": "vite",
"build": "vite build",
"lint": "eslint .",
"preview": "vite preview"
}
Sources: frontend/package.json:8
3. Component-Level Resilience
Beyond automated tooling, the testing strategy includes building resilient components that can gracefully handle runtime issues, such as failed API requests. The LocationInfo component serves as a prime example of this practice.
Sources: [frontend/src/components/LocationInfo.tsx]
3.1. Data Fetching and Error Handling
The LocationInfo component fetches data from a static JSON file (/data/live_servers.json) and is designed to handle both successful and failed outcomes. It uses try...catch blocks to manage network or parsing errors and maintains its own loading and error states.
The component's data-fetching lifecycle can be visualized as a state machine.
This diagram illustrates the possible states of the LocationInfo component during its data fetching process.
Sources: frontend/src/components/LocationInfo.tsx:40-62, frontend/src/components/LocationInfo.tsx:148-166
This defensive programming approach ensures that a failure in one part of the UI does not crash the entire application, providing a better user experience and demonstrating the kind of robust development the project advocates for.
Sources: frontend/src/pages/About.tsx:165-171, frontend/src/components/Solutions.tsx:10-16