Webapp testing

Webapp Testing

Use this skill when a coding task depends on visible browser behavior, user interaction, or UI state.

Goal

Increase frontend and local web-app success rate by validating:

1. the app actually loads
2. the intended UI appears
3. key interactions work
4. browser-visible behavior matches the code change
5. fixes are confirmed in the browser, not just in code

Core Rules

1. Confirm the app is reachable first

Before testing behavior, verify:

• the app or HTML entry point exists
• the local server or static page is actually reachable
• the intended page is loaded, not an error page or blank shell

If the app does not load, fix the setup path before testing interactions.

2. Test visible behavior, not just assumptions

Do not assume the UI works because:

• the code compiles
• a dev server starts
• a unit test passes

For browser-facing changes, confirm the visible result.

3. Reproduce the bug or target flow clearly

Before changing code or declaring a fix, restate:

• what the page should do
• what it does instead
• which user interaction reveals the issue
• which screen, route, or component is involved

4. Use the narrowest meaningful flow

Prefer testing the smallest browser flow that proves the issue or fix, such as:

• page load
• button click
• form fill and submit
• navigation change
• toggle/open/close behavior
• visible text/state update

Avoid wandering through unrelated screens.

5. Pair browser checks with code evidence

Browser testing should complement, not replace, code-level validation.

When possible, combine:

• browser verification
• targeted tests
• console/log/output evidence
• minimal reproduction steps

6. Re-test after the final edit

If the code changed again after a successful browser check, rerun the relevant browser flow.

Minis-Specific Workflow

Static HTML or minis:// pages

For simple HTML tools:

• open the minis://workspace/... entry page directly
• verify assets load correctly
• inspect visible text, layout, controls, and interactions

Local dev servers

If a local server is needed:

• start it in a way that survives shell exit
• make sure stdout/stderr are redirected
• confirm the correct URL and port
• verify the actual route under test

Browser tool usage

Use the browser to:

• open the page
• inspect readable text
• click buttons and links
• type into inputs
• verify expected state changes
• take screenshots when useful
• scroll when the flow is not fully visible

When the browser is not enough

If the issue depends on code/runtime details not obvious from the page:

• inspect logs
• rerun targeted tests
• trace the code path
• combine with root-cause-tracing or test-driven-development

Test Sequence

Use this order:

1. Identify the entry page or URL.
2. Confirm the page loads correctly.
3. Restate the expected behavior.
4. Reproduce the failing or target interaction.
5. Observe the actual result.
6. If needed, inspect related code/tests/logs.
7. Apply or verify the fix.
8. Rerun the same browser flow.
9. Check nearby related behavior if practical.
10. Summarize expected vs actual outcome.

Common Webapp Failure Modes

Watch for:

• blank page or broken asset loading
• wrong route or stale page
• button click does nothing
• text updates but state is wrong
• form submits incorrectly or not at all
• layout/visibility hides the actual bug
• fix works on one path but not a nearby one
• static preview works but local server path differs

Integration with Other Skills

• Use test-driven-development when UI behavior should also be captured with automated tests.
• Use root-cause-tracing when the visible symptom is not enough to explain the bug.
• Use finishing-a-development-branch when the web fix appears done and you need final validation and cleanup.
• Use agent-security-guard if the flow involves uploads, credentials, external services, or risky side effects.

Completion Checklist

Before calling the web task done, check:

• Did the page actually load?
• Was the intended route/screen tested?
• Was the key interaction reproduced?
• Was the result observed in the browser after the final edit?
• Were nearby related interactions checked if relevant?
• Was code/test evidence also reviewed when needed?
• Is the expected vs actual behavior clearly summarized?

Response Template

• Entry page/URL:
• Expected behavior:
• Reproduction steps:
• Actual behavior observed:
• Verification after fix:
• Nearby checks:
• Current status:
• Suggested next step:

Example Triggers

• "Test this local web app and verify the bugfix in the browser."
• "Check whether this HTML tool actually works on Minis."
• "Reproduce this frontend bug and confirm the fix visually."
• "Open the page, test the flow, and tell me expected vs actual behavior."
• "Before we call this done, verify the UI behavior in the browser."