mirror of
https://github.com/apache/superset.git
synced 2026-08-04 04:52:32 +00:00
feat(build): migrate from Prettier to Oxfmt for docs
Signed-off-by: hainenber <dotronghai96@gmail.com>
This commit is contained in:
@@ -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!_
|
||||
|
||||
@@ -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!_
|
||||
|
||||
@@ -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!_
|
||||
|
||||
@@ -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!_
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user