Skip to content

BUGBOT.md

Latest commit

 

History

History
167 lines (119 loc) · 8.25 KB

BUGBOT.md

File metadata and controls

167 lines (119 loc) · 8.25 KB
Raw

BUGBOT Rules

Core Mission

Automated test quality enforcement and bug detection for MetaMask Extension codebase

Execution Protocol

1. General Coding Guidelines

  • ALWAYS load and reference coding-guidelines
  • Applies to all files (alwaysApply: true)
  • Check for TypeScript usage in new code
  • Verify functional components and hooks are used in React
  • Check for proper component optimization (memoization, useEffect usage)
  • Verify object destructuring for props
  • Check file organization patterns
  • Verify naming conventions (PascalCase for components, camelCase for functions, use prefix for hooks, with prefix for HOCs)
  • Check code reusability (DRY principle)
  • Verify documentation requirements (TSDoc for utilities, README for components)
  • Ensure tests are written for all components and utilities
  • Verify external packages are well-maintained and necessary

Use the rules in the coding-guidelines to enforce the test quality and bug detection.

2. Unit Tests

  • ALWAYS load and reference unit testing guidelines
  • Verify test file naming pattern: *.test.{ts,tsx,js,jsx}
  • Check for proper Jest and testing library imports
  • Ensure tests are colocated with implementation files

Use the rules in the unit testing guidelines to enforce the test quality and bug detection.

3. E2E Tests

  • ALWAYS load and reference e2e-testing-guidelines
  • Verify test file naming pattern: test/e2e/**/*.spec.{ts,js}
  • Check for proper imports from the E2E framework
  • Verify Page Object Model pattern is used
  • Ensure tests are written in TypeScript (.spec.ts)

Use the rules in the e2e-testing-guidelines to enforce the test quality and bug detection.

3.1 Deprecated Pattern Detection (Non-Blocking): Prefer FixtureBuilderV2

  • Analyze only changed lines in the PR diff.
  • Scope: test/e2e/**/*.spec.{ts,js} files.
  • Goal: discourage new usage of legacy FixtureBuilder when FixtureBuilderV2 can be used.
Trigger Signals (changed lines only)
  • Legacy import introduced:
    • import FixtureBuilder from '.../fixtures/fixture-builder'
    • Regex: import\s+FixtureBuilder\s+from\s+['"].*/fixtures/fixture-builder['"]
  • Legacy instantiation introduced:
    • new FixtureBuilder(...)
    • Regex: new\s+FixtureBuilder\s*\(
Compatibility Check Before Reporting

When a trigger is found, inspect methods chained from new FixtureBuilder() in the changed file.

  • If there are no custom methods (only .build()), report it.
  • If all used methods are supported in FixtureBuilderV2, report it.
  • If any required method is not available in FixtureBuilderV2, do not report this rule.

Supported methods in FixtureBuilderV2:

  • withAddressBookController
  • withCurrencyController
  • withPermissionController
  • withPreferencesController
  • withConversionRateDisabled
  • withEnabledNetworks
  • withPermissionControllerConnectedToTestDapp
Severity and Message
  • Severity: HIGH (deprecated pattern), non-blocking.
  • Suggested comment:
    • ⚠️ DEPRECATED: This spec introduces legacy FixtureBuilder usage. Please use FixtureBuilderV2 when supported by the methods used in this test.
    • ✅ Use instead: import FixtureBuilderV2 from '.../fixtures/fixture-builder-v2' and instantiate new FixtureBuilderV2(...).

3.2 Snap E2E Tests: Require withSnapsPrivacyWarningAlreadyShown

  • Analyze only changed lines in the PR diff.
  • Scope: test/e2e/snaps/**/*.spec.{ts,js} files.
  • Goal: ensure snap specs that use FixtureBuilderV2 chain .withSnapsPrivacyWarningAlreadyShown() so the snap privacy warning modal is not shown during test runs (reduces flakiness and keeps tests focused on snap behavior).
Trigger Signals (changed lines only)
  • File path matches: test/e2e/snaps/**/*.spec.{ts,js}.
  • FixtureBuilderV2 instantiation in the file: new FixtureBuilderV2(.
Compatibility Check Before Reporting

When both conditions hold, inspect the fixture builder chain in the same withFixtures / test block.

  • If the chain includes .withSnapsPrivacyWarningAlreadyShown() (anywhere in the chain), do not report.
  • If the chain does not include .withSnapsPrivacyWarningAlreadyShown(), report this rule.
Severity and Message
  • Severity: MEDIUM (test quality), non-blocking.
  • Suggested comment:
    • 📋 Snap E2E tests should use \.withSnapsPrivacyWarningAlreadyShown()` on the fixture builder so the snap privacy warning is already dismissed. This avoids extra UI steps and reduces flakiness.`
    • ✅ Add \.withSnapsPrivacyWarningAlreadyShown()` to the FixtureBuilderV2 chain, e.g. `new FixtureBuilderV2().withSnapsPrivacyWarningAlreadyShown().build()` or chain it with other methods.`

4. Controller Guidelines

  • ALWAYS load and reference controller-guidelines
  • Auto-detect controller files based on naming patterns: *Controller.ts, *Controller.js, *-controller.ts, *-controller.js
  • Only apply when analyzing controller files
  • Verify controller inherits from BaseController
  • Verify that controller has state
  • Check state management patterns (partial state acceptance, default state functions, state metadata)
  • Verify constructor uses single options bag pattern
  • Check for messenger usage instead of callbacks for inter-controller communication
  • Verify selectors are used instead of getter methods for derived state
  • Check that action methods model high-level user actions, not low-level setters
  • Verify minimal state (no derived values stored)
  • Check proper lifecycle management (initialization, cleanup in destroy())

Use the rules in the controller-guidelines to enforce the test quality and bug detection.

5. Front-End Performance Guidelines

5.1 Hooks & Effects Optimization

  • ALWAYS load and reference front-end-performance-hooks-effects
  • Auto-detect files: use*.{ts,tsx,js,jsx}, *.{tsx,jsx}
  • Check useEffect usage patterns, dependency management (never use JSON.stringify)
  • Verify cleanup functions for intervals, subscriptions, and async operations
  • Ensure proper hook usage (unconditional calls, refs for persistent values)

Use the rules in the front-end-performance-hooks-effects to enforce the test quality and bug detection.

5.2 React Compiler & Anti-Patterns

  • ALWAYS load and reference front-end-performance-react-compiler
  • Auto-detect files: *.{tsx,jsx,ts,js}
  • Verify manual memoization for cross-file dependencies, Redux selectors, and external state
  • Keep existing useMemo/useCallback for effect dependencies
  • Check proper list keys and avoid over-memoization

Use the rules in the front-end-performance-react-compiler to enforce the test quality and bug detection.

5.3 Rendering Performance

  • ALWAYS load and reference front-end-performance-rendering
  • Auto-detect files: *.{tsx,jsx,ts,js}
  • Verify unique keys, virtualization for long lists, and React.memo usage
  • Check code splitting (React.lazy/Suspense) and pagination patterns
  • Ensure expensive computations use useMemo or Redux selectors

Use the rules in the front-end-performance-rendering to enforce the test quality and bug detection.

5.4 State Management & Redux

  • ALWAYS load and reference front-end-performance-state-management
  • Auto-detect files: *selector*.{ts,js}, *reducer*.{ts,js}, *ducks*.{ts,js}, *slice*.{ts,js}
  • Verify immutable reducers, no side effects, and serializable state
  • Check normalized state structure (byId/allIds) and proper selector memoization
  • Ensure efficient selector patterns (avoid Object.values() without memoization, combine multiple useSelector calls)

Use the rules in the front-end-performance-state-management to enforce the test quality and bug detection.