Files
superset2/docs/developer_docs/testing/overview.md
Claude Code 04451766e7 fix(docs): tighten onBrokenLinks to throw and fix surfaced broken links
Previously docusaurus.config.ts had `onBrokenLinks: 'warn'`, so broken
internal links produced advisory warnings during build but didn't gate
merges. Tightening to `throw` surfaces every broken internal route at
build time. Three classes of issue fell out:

1. Stale `/docs/...` and `/docs/6.0.0/...` references in the 6.0.0
   versioned snapshot. The user-facing docs section was renamed
   `docs` → `user-docs` (routeBasePath) at some point after 6.0.0 was
   cut, but the snapshot's links still pointed at the old prefix. The
   live site redirects /docs/* → /user-docs/* at runtime, but
   Docusaurus's onBrokenLinks checker doesn't honor redirects.
   Bulk-rewrote /docs/* → /user-docs/* across the snapshot (and one
   /docs/api → /developer-docs/api).

2. Bare-relative MDX links like `[Label](./mcp)` (no .md/.mdx
   extension). Docusaurus renders an absolute href in SSR HTML, so
   static crawlers see correct links — BUT React Router's `<Link>`
   component on the client side resolves the bare path relative to
   the current URL on click, so when the page URL has a trailing
   slash (e.g. /extensions/overview/), `./mcp` becomes
   /extensions/overview/mcp (404). This is exactly the broken-flow a
   user reported on /developer-docs/extensions/overview/. Added the
   `.md`/`.mdx` extension to all 44 such links across 17 files; this
   makes Docusaurus resolve them to the canonical doc URL at the
   <Link> level, so SPA navigation works regardless of trailing slash.

3. Miscellaneous content fixes:
   - 4 `/configuration/feature-flags` references in 6.0.0 snapshot
     pointed at a page that doesn't exist in that version (the
     dedicated feature-flags page was added later). Repointed to the
     `#feature-flags` anchor inside `configuring-superset.mdx`.
   - 3 references to `superset-core/src/superset_core/rest_api/decorators.py`
     in extensions docs were rendered as relative URLs, resolving to
     /developer-docs/extensions/superset-core/... (404). Converted to
     absolute GitHub URLs.
   - 1 `/storybook/?path=...` link in extensions/components/index.mdx
     pointed at a non-existent route. Repointed to the existing
     `/developer-docs/testing/storybook` page that explains how to
     run Storybook locally.
   - 4 unclosed-paren markdown links in 6.0.0 installation-methods.mdx
     (pre-existing source bugs).

Build now passes with `onBrokenLinks: 'throw'`. Note that
`onBrokenAnchors` is still `'warn'` (default); a separate effort
should tighten that and fix the surviving anchor warnings (currently
~60 instances of `/community#superset-community-calendar`).
2026-05-13 20:17:46 -07:00

163 lines
5.7 KiB
Markdown

---
title: Overview
sidebar_position: 1
---
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
# Overview
Apache Superset follows a comprehensive testing strategy that ensures code quality, reliability, and maintainability. This section covers all aspects of testing in the Superset ecosystem, from unit tests to end-to-end testing workflows.
## Testing Philosophy
Superset embraces a testing pyramid approach:
- **Unit Tests**: Fast, isolated tests for individual components and functions
- **Integration Tests**: Tests that verify component interactions and API endpoints
- **End-to-End Tests**: Full user journey testing in browser environments
## Testing Documentation
### Frontend Testing
- **[Frontend Testing](./frontend-testing.md)** - Jest, React Testing Library, and component testing strategies
### 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
## 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)
- **Test Data Management**: Use factories and fixtures for consistent test data
## Running Tests
### Quick Commands
```bash
# Frontend unit tests
npm run test
# Backend unit tests
pytest tests/unit_tests/
# End-to-end tests
npm run playwright:test
# All tests with coverage
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
4. **Verify Coverage**: Ensure adequate test coverage for new code
## 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
## Getting Started
1. **Set up Testing Environment**: Follow the development setup guide
2. **Run Existing Tests**: Familiarize yourself with the test suite
3. **Write Your First Test**: Start with a simple unit test
4. **Learn Testing Patterns**: Study existing tests for patterns and conventions
## Topics to be covered:
- Testing strategy and pyramid
- Test-driven development (TDD) for plugins
- Continuous integration and automated testing
- Code coverage and quality metrics
- Testing tools and frameworks overview
- Mock data and test fixtures
- Performance testing and benchmarking
- Accessibility testing automation
- Cross-browser and device testing
- Regression testing strategies
## 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
- **Accessibility testing** - Screen reader and keyboard navigation
## Testing Tools
- **Jest** - Unit and integration testing framework
- **React Testing Library** - Component testing utilities
- **Playwright** - End-to-end testing (replacing Cypress)
- **Storybook** - Component development and testing
---
*This documentation is under active development. Check back soon for updates!*