browser-testing

Skill: Browser-based End-to-End Testing

1. Overview

This skill defines an end-to-end (E2E) testing process that does not rely on traditional unit testing frameworks, but instead uses chrome-dev-tools or similar browser tools for manual or semi-automated interface testing.

All test cases are recorded and managed as structured Markdown files.

2. When to Use

• When test cases need to be created or executed for a Space application in the project.
• When it is necessary to verify whether a feature works as expected both locally and after deployment.
• When the testing process and results need to be recorded for review.

3. Testing Process

1. Local Testing First: After development is completed in the local environment, first run the application locally and execute end-to-end tests according to the test cases.
2. Deployment Testing: After all local tests pass, push the code to the main branch to trigger automatic deployment of Hugging Face Spaces.
3. Verify Deployment: On the deployed Space page, repeat the test cases to ensure that online functionality is consistent with local.

4. Test Case Specification

A) Storage Location

The test cases for each Space application are stored in their respective tests/ directory. For example:some-proj/tests/。

B) File Structure

Each test case is an independent Markdown file, and its content structure is defined by the template templates/test-case.md.template .

• File Header:
  • Creation Time: The timestamp when the test case was created.
  • Commit Hash: The corresponding Git Commit hash at creation time.
  • Commit Message: The corresponding Git Commit message at creation time.
• Core Definition:
  • Test Name: A short description of the test case.
  • Test Purpose: A detailed explanation of the feature or fixed issue that this test case is intended to verify.
• Environment Information:
  • Local Running and Deployment Method: Clearly explain how to start the application locally and how to trigger deployment.
• Execution and Results:
  • Test Steps: A series of clear, reproducible operation steps.
  • Expected Results: Describe the state the system should reach after executing the test steps.
  • Actual Results When Passing: When the test passes successfully, record the observed actual results here, including:
    • Screenshot Path: The storage path of the automatically captured screenshots of key pages.
    • Verification Status: The verification result after comparing the screenshot content with the expected result description (pass/fail).
    • Spoken Standard: The visual description of the expected result spoken by the user. These records serve as evidence that the test passed.

C) Create Test Case

1. Use date +'%Y-%m-%d-%H-%M' to get the current timestamp.
2. Use git log -1 --pretty=%H%n%s to get the latest Commit information.
3. Copy browser-testing/templates/test-case.md.template Template content.
4. Fill in the placeholders in the template, and write detailed test steps and expected results.
5. Save the newly created test case file to the corresponding Space's tests/ directory.
6. Create a subdirectory with the same name for each test case to store test artifacts such as screenshots. For example:some-proj/tests/YYYY-MM-DD-HH-mm-测试名称/。

5. Template resources

• templates/test-case.md.template: Markdown template used to create new test cases.