feat(build): migrate from Prettier to Oxfmt for performant code formatting (#42434)

docs/developer_docs/testing/backend-testing.md

@@ -159,13 +159,13 @@ Use `--concurrency=1` to limit resource usage on your dev machine.
 
 ### Troubleshooting
 
-| Problem | Solution |
-|---|---|
-| Beat shows no output | Ensure `beat_schedule` is defined in your `CeleryConfig` and `--loglevel=info` is set |
+| Problem                                                    | Solution                                                                                                              |
+| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| Beat shows no output                                       | Ensure `beat_schedule` is defined in your `CeleryConfig` and `--loglevel=info` is set                                 |
 | "Report Schedule is still working, refusing to re-compute" | Previous executions are stuck. Reset with: `UPDATE report_schedule SET last_state = 'Not triggered' WHERE id = <id>;` |
-| Task backlog overwhelming the worker | Flush Redis: `redis-cli FLUSHDB`, then restart Beat and Worker |
-| Screenshot timeout | Ensure your frontend dev server is running and `WEBDRIVER_BASEURL` matches its URL |
+| Task backlog overwhelming the worker                       | Flush Redis: `redis-cli FLUSHDB`, then restart Beat and Worker                                                        |
+| Screenshot timeout                                         | Ensure your frontend dev server is running and `WEBDRIVER_BASEURL` matches its URL                                    |
 
 ---
 
-*This documentation is under active development. Check back soon for updates!*
+_This documentation is under active development. Check back soon for updates!_

docs/developer_docs/testing/ci-cd.md

@@ -59,6 +59,7 @@ pre-commit run --all-files
 ## GitHub Actions
 
 Key workflows:
+
 - `test-frontend.yml` - Frontend tests
 - `test-backend.yml` - Backend tests
 - `docker.yml` - Docker image builds
@@ -67,4 +68,4 @@ Key workflows:
 
 ---
 
-*This documentation is under active development. Check back soon for updates!*
+_This documentation is under active development. Check back soon for updates!_

docs/developer_docs/testing/frontend-testing.md

@@ -58,4 +58,4 @@ npm run test -- MyComponent.test.tsx
 
 ---
 
-*This documentation is under active development. Check back soon for updates!*
+_This documentation is under active development. Check back soon for updates!_

docs/developer_docs/testing/overview.md

@@ -37,26 +37,32 @@ Superset embraces a testing pyramid approach:
 ## Testing Documentation
 
 ### Frontend Testing
+
 - **[Frontend Testing](./frontend-testing.md)** - Jest, React Testing Library, and component testing strategies
 
-### Backend Testing  
+### Backend Testing
+
 - **[Backend Testing](./backend-testing.md)** - pytest, database testing, and API testing patterns
 
 ### End-to-End Testing
+
 - **[E2E Testing](./e2e-testing.md)** - Playwright testing for complete user workflows
 
 ### CI/CD Integration
+
 - **[CI/CD](./ci-cd.md)** - Continuous integration, automated testing, and deployment pipelines
 
 ## Testing Tools & Frameworks
 
 ### Frontend
+
 - **Jest**: JavaScript testing framework for unit and integration tests
 - **React Testing Library**: Component testing utilities focused on user behavior
 - **Playwright**: Modern end-to-end testing for web applications
 - **Storybook**: Component development and visual testing environment
 
 ### Backend
+
 - **pytest**: Python testing framework with powerful fixtures and plugins
 - **SQLAlchemy Test Utilities**: Database testing and transaction management
 - **Flask Test Client**: API endpoint testing and request simulation
@@ -64,12 +70,14 @@ Superset embraces a testing pyramid approach:
 ## Best Practices
 
 ### Writing Effective Tests
+
 1. **Test Behavior, Not Implementation**: Focus on what the code should do, not how it does it
 2. **Keep Tests Independent**: Each test should be able to run in isolation
 3. **Use Descriptive Names**: Test names should clearly describe what is being tested
 4. **Arrange, Act, Assert**: Structure tests with clear setup, execution, and verification phases
 
 ### Test Organization
+
 - **Colocation**: Place test files near the code they test
 - **Naming Conventions**: Use consistent naming patterns for test files and functions
 - **Test Categories**: Organize tests by type (unit, integration, e2e)
@@ -78,11 +86,12 @@ Superset embraces a testing pyramid approach:
 ## Running Tests
 
 ### Quick Commands
+
 ```bash
 # Frontend unit tests
 npm run test
 
-# Backend unit tests  
+# Backend unit tests
 pytest tests/unit_tests/
 
 # End-to-end tests
@@ -93,6 +102,7 @@ npm run test:coverage
 ```
 
 ### Test Development Workflow
+
 1. **Write Failing Test**: Start with a test that describes the desired behavior
 2. **Implement Feature**: Write the minimum code to make the test pass
 3. **Refactor**: Improve code quality while keeping tests green
@@ -101,11 +111,13 @@ npm run test:coverage
 ## Testing in Development
 
 ### Test-Driven Development (TDD)
+
 - Write tests before implementation
 - Use tests to guide design decisions
 - Maintain fast feedback loops
 
 ### Continuous Testing
+
 - Run tests automatically on code changes
 - Integrate testing into development workflow
 - Use pre-commit hooks for test validation
@@ -133,18 +145,21 @@ npm run test:coverage
 ## Testing Levels
 
 ### Unit Testing
+
 - **Component testing** - Individual React components
 - **Function testing** - Data transformation and utility functions
 - **Hook testing** - Custom React hooks
 - **Service testing** - API clients and business logic
 
 ### Integration Testing
+
 - **API integration** - Backend service communication
 - **Component integration** - Multi-component workflows
 - **Data flow testing** - End-to-end data processing
 - **Plugin lifecycle testing** - Installation and activation
 
 ### End-to-End Testing
+
 - **User workflow testing** - Complete user journeys
 - **Cross-browser testing** - Browser compatibility
 - **Performance testing** - Load and stress testing
@@ -159,4 +174,4 @@ npm run test:coverage
 
 ---
 
-*This documentation is under active development. Check back soon for updates!*
+_This documentation is under active development. Check back soon for updates!_

docs/developer_docs/testing/storybook.md

@@ -102,8 +102,9 @@ storybook/stories/<package>/index.js
    ```
 
    Use the `|` separator for nested stories:
+
    ```javascript
-   storyPath: '@superset-ui/package|Category|Subcategory'
+   storyPath: '@superset-ui/package|Category|Subcategory';
    ```
 
 ## Best Practices

docs/developer_docs/testing/testing-guidelines.md

@@ -61,7 +61,7 @@ One of the most important points of RTL is accessibility and this is also a very
 By using the `name` option we can point to the items by their accessible name. For example:
 
 ```jsx
-screen.getByRole('button', { name: /hello world/i })
+screen.getByRole('button', { name: /hello world/i });
 ```
 
 Using the `name` property also avoids breaking the tests in the future if other components with the same role are added.
@@ -108,10 +108,12 @@ Cleaning the state of the application, such as resetting the DB, or in general,
 - Unnecessary when using `cy.get()`. When the selector should wait for a request to happen, aliases would come in handy:
 
 ```js
-cy.intercept('GET', '/users', [{ name: 'Maggy' }, { name: 'Joan' }]).as('getUsers')
-cy.get('#fetch').click()
-cy.wait('@getUsers') // <--- wait explicitly for this route to finish
-cy.get('table tr').should('have.length', 2)
+cy.intercept('GET', '/users', [{ name: 'Maggy' }, { name: 'Joan' }]).as(
+  'getUsers',
+);
+cy.get('#fetch').click();
+cy.wait('@getUsers'); // <--- wait explicitly for this route to finish
+cy.get('table tr').should('have.length', 2);
 ```
 
 ### Accessibility and Resilience