What is this about?

Remove static hex color values from test files in favor of design tokens to ensure consistent color usage across our mobile codebase.

Scenario

Our codebase currently contains static hex color values in test files. We want to ensure consistent color usage by leveraging our design token system (@metamask/design-tokens) instead of hard-coded hex values.

Design

N/A - This is a technical improvement for test files.

Technical Details

We use @metamask/design-tokens to maintain consistent colors across our application. The eslint rule @metamask/design-tokens/color-no-hex helps enforce this. Test files need to be updated to use these tokens instead of static hex values.

Examples of required changes:

// Before
expect(themeValue.brandColors.black).toStrictEqual('#000000');

// After
import { brandColors } from '@metamask/design-tokens';
expect(themeValue.brandColors.black).toStrictEqual(brandColors.black);

// Before
const mockColor = '#0376c9';

// After
import { lightTheme } from '@metamask/design-tokens';
const mockColor = lightTheme.colors.primary.default;

Steps to complete:

1. Run eslint to find hex colors:

   yarn eslint '**/*.test.{js,ts,tsx}' --rule '@metamask/design-tokens/color-no-hex: "error"'

2. For each hex value found:

   • Verify it's actually a color (some #123 values might be IDs or other non-color values)
   • Find the corresponding design token in the design-tokens repository
   • Import the appropriate token (usually brandColors or lightTheme)
   • Replace the hex value with the corresponding token

3. Run tests:

   yarn test

Notes:

• Most color tokens can be found in:
  • brandColors for brand-specific colors
  • lightTheme.colors for theme-specific colors
• If you find a #123 format (3 digits) that isn't a color, you can leave it as is
• When in doubt about which token to use, look at similar components/tests that have already been updated

Threat Modeling Framework

N/A - This change only affects test files and doesn't impact production code.

Acceptance Criteria

• All hex color values in test files replaced with appropriate design tokens
• Tests passing
• No eslint warnings for @metamask/design-tokens/color-no-hex rule
• PR includes examples of changes made in the description for reviewer reference

Stakeholder review needed before the work gets merged

• Engineering (needed in most cases)
• Design
• Product
• QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• Security
• Legal
• Marketing
• Management
• Other

References

• Design Tokens Source
• Example PR with similar changes: [Link to your recent PR with the diff shown above]