Subskill: Test Scaffolder

This subskill establishes the safety net of existing and new visual/functional tests before any codebase modifications occur, ensuring that no rendering or logical regressions are introduced during modernization.

---

1. Test Verification Lifecycle

1. Verify Existing Tests:

   • Inspect the corresponding unit test file (e.g., IndexedDBViews.test.ts for IndexedDBViews.ts) under the target folder or test/unittests/.
   • Check for logic tests (verifying presenter interactions and view function callbacks).
   • Check for screenshot or interaction tests (under test/interactions/ or test/goldens/) matching the visual component to verify layout and styling.

2. Detect Sub-component Testing Gaps (Hybrid Files):

   • Identify if the existing test suite only covers one class of a hybrid file while missing another class being migrated (e.g., tests exist for IDBDatabaseView but are scarce/missing for IDBDataView).

3. Scaffold Missing Tests:

   • If logic tests are missing, draft tests verifying that callbacks trigger the expected state updates or model interactions.
   • If rendering/screenshot tests are missing or inadequate for the legacy class being migrated, draft a basic Mocha/Chai rendering test.
   • Verify that the component compiles and mounts successfully inside a synthetic DOM helper or unit-test container.
   • Screenshot Tests: Create screenshot tests to establish visual baselines before refactoring. Follow the pattern seen in CategorizedBreakpointsSidebarPane.test.ts:

     • First run the test having renderElementIntoDOM with {includeCommonStyles: true} to ensure styles are applied.

     • The first run will generate the screenshot.

     • Now try removing {includeCommonStyles: true} to see if class is adding the styles itself. If the test pass, keep the version without {includeCommonStyles: true}. Otherwise, bring it back.

     • Screenshot tests are unittests that render either the full widget (if not migrated to the MVP architecture) or its view function (if already in MVP shape).

     • When testing view-separated components, prefer testing the View function (e.g., DEFAULT_VIEW) directly by passing mock state and callbacks.

     • Use assertScreenshot to capture and verify the visual output.

     • Example structure:

       it('renders the view', async () => {
         const target = document.createElement('div');
         renderElementIntoDOM(target, {includeCommonStyles: true});
         MyComponent.DEFAULT_VIEW(mockViewInput, undefined, target);
         await assertScreenshot('my_component/base.png');
       });

4. Wait for confirmation:

   • Wait for an explicit confirmation from the user (or Parent Orchestrator Agent) before proceeding to the next step.

---

2. Environment Detection & Test Execution Guide

Always detect the execution environment first to run tests successfully:

Scenario A: Google-Internal Cog/Cider Workspaces (PRIMARY PATH for Google Workspaces)

• Detection: Triggered if the workspace path starts with /google/cog/ or /google/src/.

• Why it is required: Raw commands like npm run test or autoninja fail because they lack Google cloudtop/virtualization wrapper configurations.

• Resolution Steps:

  1. Do not run npm run test or standard autoninja directly.

  2. Leverage the Google-specific Cider testing script to compile and run tests in the cloud workspace:

     python3 internal/infra/scripts/cider/init_workspace.py test /google/cog/cloud/username/workspace_name --test_filter=front_end/panels/application/IndexedDBViews.test.ts

Scenario B: Standard Chromium Environment (Fallback)

• Detection: Triggered if in an open-source or local standard Chromium checkout without Cog paths.

• Troubleshooting vpython3 / depot_tools errors:

  • Symptom: Command fails with vpython3: command not found or python3_bin_reldir.txt not found.

  • Resolution Steps:

    1. Export depot_tools path:

       export PATH=$PATH:/path/to/depot_tools

    2. Initialize the depot_tools binaries by running update/gclient help once from the checkout root:

       update_depot_tools

    3. Execute the tests:

       npm run test -- front_end/panels/application/IndexedDBViews.test.ts

Scenario C: ESLint TS Module Resolution Failure (ERR_UNKNOWN_FILE_EXTENSION)

• Symptom: Running lint checks fails with: TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for scripts/eslint_rules/...

• Resolution Steps:

  1. Compile the custom eslint rules and build assets first so that Node can parse the rules:

     npm run build

Scenario D: Screenshot Test Fails (Visual Diffs > 0%)

• Symptom: The test runs but fails with a percentage difference in visual regression.
• Resolution Steps:
  1. Do NOT ask the user to accept the new screenshot yet.
  2. Inspect the failure log to see if it is a layout shift or a missing style.
  3. If it's a layout shift, check if you replaced a block element with an inline element (e.g. div -> span).
  4. If styles are missing, verify if the test wrapper needs {includeCommonStyles: true}.

---

🔍 Mental Audit (Internal Self-Correction)

Before reporting back or committing, re-read the instructions and verify:

1. ❓ Coverage: Did I cover all classes in the file, or only the main one?
2. ❓ Stability: Can the tests run repeatedly without flakiness?
3. ❓ Integrations: Did I verify that the component mounts correctly?