QT/superset2
1
0
Fork 0
mirror of https://github.com/apache/superset.git synced 2026-04-07 10:31:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: bifurcate documentation into user and admin sections (#38196)

Browse Source 
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Evan Rusackas
2026-02-26 16:29:08 -05:00
committed by GitHub
parent 8a053bbe07
commit 6589ee48f9
171 changed files with 10899 additions and 2866 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/developer_docs/testing/backend-testing.md Normal file
View File

@@ -0,0 +1,68 @@
---
title: Backend Testing
sidebar_position: 3
---
<!--
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.
-->
# Backend Testing
🚧 **Coming Soon** 🚧
Complete guide for testing Superset's Python backend, APIs, and database interactions.
## Topics to be covered:
- Pytest configuration and fixtures
- Unit testing best practices
- Integration testing with databases
- API endpoint testing
- Mocking strategies and patterns
- Testing async operations with Celery
- Security testing guidelines
- Performance and load testing
- Test database setup and teardown
- Coverage requirements
## Quick Commands
```bash
# Run all backend tests
pytest
# Run specific test file
pytest tests/unit_tests/specific_test.py
# Run with coverage
pytest --cov=superset
# Run tests in parallel
pytest -n auto
# Run only unit tests
pytest tests/unit_tests/
# Run only integration tests
pytest tests/integration_tests/
```
---
*This documentation is under active development. Check back soon for updates!*

70
docs/developer_docs/testing/ci-cd.md Normal file
View File

@@ -0,0 +1,70 @@
---
title: CI/CD and Automation
sidebar_position: 5
---
<!--
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.
-->
# CI/CD and Automation
🚧 **Coming Soon** 🚧
Understanding Superset's continuous integration and deployment pipelines.
## Topics to be covered:
- GitHub Actions workflows
- Pre-commit hooks configuration
- Automated testing pipelines
- Code quality checks (ESLint, Prettier, Black, MyPy)
- Security scanning (Dependabot, CodeQL)
- Docker image building and publishing
- Release automation
- Performance benchmarking
- Coverage reporting and tracking
## Pre-commit Hooks
```bash
# Install pre-commit hooks
pre-commit install
# Run all hooks on staged files
pre-commit run
# Run specific hook
pre-commit run mypy
# Run on all files (not just staged)
pre-commit run --all-files
```
## GitHub Actions
Key workflows:
- `test-frontend.yml` - Frontend tests
- `test-backend.yml` - Backend tests
- `docker.yml` - Docker image builds
- `codeql.yml` - Security analysis
- `release.yml` - Release automation
---
*This documentation is under active development. Check back soon for updates!*

227
docs/developer_docs/testing/e2e-testing.md Normal file
View File

@@ -0,0 +1,227 @@
---
title: End-to-End Testing
sidebar_position: 4
---
<!--
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.
-->
# End-to-End Testing
Apache Superset uses Playwright for end-to-end testing, migrating from the legacy Cypress tests.
## Running Tests
### Playwright (Recommended)
```bash
cd superset-frontend
# Run all tests
npm run playwright:test
# or: npx playwright test
# Run specific test file
npx playwright test tests/auth/login.spec.ts
# Run with UI mode for debugging
npm run playwright:ui
# or: npx playwright test --ui
# Run in headed mode (see browser)
npm run playwright:headed
# or: npx playwright test --headed
# Debug specific test file
npm run playwright:debug tests/auth/login.spec.ts
# or: npx playwright test --debug tests/auth/login.spec.ts
```
### Cypress (Deprecated)
Cypress tests are being migrated to Playwright. For legacy tests:
```bash
cd superset-frontend/cypress-base
npm run cypress-run-chrome # Headless
npm run cypress-debug # Interactive UI
```
## Project Architecture
```
superset-frontend/playwright/
├── components/core/ # Reusable UI components
├── pages/ # Page Object Models
├── tests/ # Test files organized by feature
├── utils/ # Shared constants and utilities
└── playwright.config.ts
```
## Design Principles
We follow **YAGNI** (You Aren't Gonna Need It), **DRY** (Don't Repeat Yourself), and **KISS** (Keep It Simple, Stupid) principles:
- Build only what's needed now
- Reuse existing patterns and components
- Keep solutions simple and maintainable
## Page Object Pattern
Each page object encapsulates:
- **Actions**: What you can do on the page
- **Queries**: Information you can get from the page
- **Selectors**: Centralized in private static SELECTORS constant
- **NO Assertions**: Keep assertions in test files
**Example Page Object:**
```typescript
export class AuthPage {
// Selectors centralized in the page object
private static readonly SELECTORS = {
LOGIN_FORM: '[data-test="login-form"]',
USERNAME_INPUT: '[data-test="username-input"]',
} as const;
// Actions - what you can do
async loginWithCredentials(username: string, password: string) {}
// Queries - information you can get
async getCurrentUrl(): Promise<string> {}
// NO assertions - those belong in tests
}
```
**Example Test:**
```typescript
import { test, expect } from '@playwright/test';
import { AuthPage } from '../../pages/AuthPage';
import { LOGIN } from '../../utils/urls';
test('should login with correct credentials', async ({ page }) => {
const authPage = new AuthPage(page);
await authPage.goto();
await authPage.loginWithCredentials('admin', 'general');
// Assertions belong in tests, not page objects
expect(await authPage.getCurrentUrl()).not.toContain(LOGIN);
});
```
## Core Components
Reusable UI interaction classes for common elements (`components/core/`):
- **Form**: Container with properly scoped child element access
- **Input**: Supports `fill()`, `type()`, and `pressSequentially()` methods
- **Button**: Standard click, hover, focus interactions
**Usage Example:**
```typescript
import { Form } from '../components/core';
const loginForm = new Form(page, '[data-test="login-form"]');
const usernameInput = loginForm.getInput('[data-test="username-input"]');
await usernameInput.fill('admin');
```
## Test Reports
Playwright generates multiple reports for better visibility:
```bash
# View interactive HTML report (opens automatically on failure)
npm run playwright:report
# or: npx playwright show-report
# View test trace for debugging failures
npx playwright show-trace test-results/[test-name]/trace.zip
```
### Report Types
- **List Reporter**: Shows progress and summary table in terminal
- **HTML Report**: Interactive web interface with screenshots, videos, and traces
- **JSON Report**: Machine-readable format in `test-results/results.json`
- **GitHub Actions**: Annotations in CI for failed tests
### Debugging Failed Tests
When tests fail, Playwright automatically captures:
- **Screenshots** at the point of failure
- **Videos** of the entire test run
- **Traces** with timeline and network activity
- **Error context** with detailed debugging information
All debugging artifacts are available in the HTML report for easy analysis.
## Configuration
- **Config**: `playwright.config.ts` - matches Cypress settings
- **Base URL**: `http://localhost:8088` (assumes Superset running)
- **Browsers**: Chrome only for Phase 1 (YAGNI)
- **Retries**: 2 in CI, 0 locally (matches Cypress)
## Contributing Guidelines
### Adding New Tests
1. **Check existing components** before creating new ones
2. **Use page objects** for page interactions
3. **Keep assertions in tests**, not page objects
4. **Follow naming conventions**: `feature.spec.ts`
### Adding New Components
1. **Follow YAGNI**: Only build what's immediately needed
2. **Use Locator-based scoping** for proper element isolation
3. **Support both string selectors and Locator objects** via constructor overloads
4. **Add to `components/core/index.ts`** for easy importing
### Adding New Page Objects
1. **Centralize selectors** in private static SELECTORS constant
2. **Import shared constants** from `utils/urls.ts`
3. **Actions and queries only** - no assertions
4. **Use existing components** for DOM interactions
## Migration from Cypress
When porting Cypress tests:
1. **Port the logic**, not the implementation
2. **Use page objects** instead of inline selectors
3. **Replace `cy.intercept/cy.wait`** with `page.waitForRequest()`
4. **Use shared constants** from `utils/urls.ts`
5. **Follow the established patterns** shown in `tests/auth/login.spec.ts`
## Best Practices
- **Centralize selectors** in page objects
- **Centralize URLs** in `utils/urls.ts`
- **Use meaningful test descriptions**
- **Keep page objects action-focused**
- **Put assertions in tests, not page objects**
- **Follow the existing patterns** for consistency

61
docs/developer_docs/testing/frontend-testing.md Normal file
View File

@@ -0,0 +1,61 @@
---
title: Frontend Testing
sidebar_position: 2
---
<!--
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.
-->
# Frontend Testing
🚧 **Coming Soon** 🚧
Comprehensive guide for testing Superset's frontend components and features.
## Topics to be covered:
- Jest configuration and setup
- React Testing Library best practices
- Component testing strategies
- Redux store testing
- Async operations and API mocking
- Snapshot testing guidelines
- Coverage requirements and reporting
- Debugging test failures
- Performance testing for UI components
## Quick Commands
```bash
# Run all frontend tests
npm run test
# Run tests in watch mode
npm run test -- --watch
# Run tests with coverage
npm run test -- --coverage
# Run specific test file
npm run test -- MyComponent.test.tsx
```
---
*This documentation is under active development. Check back soon for updates!*

162
docs/developer_docs/testing/overview.md Normal file
View File

@@ -0,0 +1,162 @@
---
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)** - Jest, React Testing Library, and component testing strategies
### Backend Testing
- **[Backend Testing](./backend-testing)** - pytest, database testing, and API testing patterns
### End-to-End Testing
- **[E2E Testing](./e2e-testing)** - Playwright testing for complete user workflows
### CI/CD Integration
- **[CI/CD](./ci-cd)** - 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!*

114
docs/developer_docs/testing/storybook.md Normal file
View File

@@ -0,0 +1,114 @@
---
title: Storybook
sidebar_position: 5
---
<!--
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.
-->
# Storybook
Superset uses [Storybook](https://storybook.js.org/) for developing and testing UI components in isolation. Storybook provides a sandbox to build components independently, outside of the main application.
## Public Storybook
A public Storybook with components from the `master` branch is available at:
**[apache-superset.github.io/superset-ui](https://apache-superset.github.io/superset-ui/?path=/story/*)**
## Running Locally
### Main Superset Storybook
To run the main Superset Storybook locally:
```bash
cd superset-frontend
# Start Storybook (opens at http://localhost:6006)
npm run storybook
# Build static Storybook
npm run build-storybook
```
### @superset-ui Package Storybook
The `@superset-ui` packages have a separate Storybook for component library development:
```bash
cd superset-frontend
# Install dependencies and bootstrap packages
npm ci && npm run bootstrap
# Start the @superset-ui Storybook (opens at http://localhost:9001)
cd packages/superset-ui-demo
npm run storybook
```
## Adding Stories
### To an Existing Package
If stories already exist for the package, extend the `examples` array in the package's story file:
```
storybook/stories/<package>/index.js
```
### To a New Package
1. Add package dependencies:
```bash
npm install <package>
```
2. Create a story folder matching the package name:
```bash
mkdir storybook/stories/superset-ui-<package>/
```
3. Create an `index.js` file with the story configuration:
```javascript
export default {
examples: [
{
storyPath: '@superset-ui/package',
storyName: 'My Story',
renderStory: () => <MyComponent />,
},
],
};
```
Use the `|` separator for nested stories:
```javascript
storyPath: '@superset-ui/package|Category|Subcategory'
```
## Best Practices
- **Isolate components**: Stories should render components in isolation, without application context
- **Show variations**: Create stories for different states, sizes, and configurations
- **Document props**: Use Storybook's controls to expose configurable props
- **Test edge cases**: Include stories for loading states, error states, and empty states

129
docs/developer_docs/testing/testing-guidelines.md Normal file
View File

@@ -0,0 +1,129 @@
---
title: Testing Guidelines and Best Practices
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.
-->
# Testing Guidelines and Best Practices
We feel that tests are an important part of a feature and not an additional or optional effort. That's why we colocate test files with functionality and sometimes write tests upfront to help validate requirements and shape the API of our components. Every new component or file added should have an associated test file with the `.test` extension.
We use Jest, React Testing Library (RTL), and Cypress to write our unit, integration, and end-to-end tests. For each type, we have a set of best practices/tips described below:
## Jest
### Write simple, standalone tests
The importance of simplicity is often overlooked in test cases. Clear, dumb code should always be preferred over complex ones. The test cases should be pretty much standalone and should not involve any external logic if not absolutely necessary. That's because you want the corpus of the tests to be easy to read and understandable at first sight.
### Avoid nesting when you're testing
Avoid the use of `describe` blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this awesome [article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by [Kent C. Dodds](https://kentcdodds.com/) about this topic.
### No warnings!
Your tests shouldn't trigger warnings. This is really common when testing async functionality. It's really difficult to read test results when we have a bunch of warnings.
### Example
You can find an example of a test [here](https://github.com/apache/superset/blob/e6c5bf4/superset-frontend/src/common/hooks/useChangeEffect/useChangeEffect.test.ts).
## React Testing Library (RTL)
### Keep accessibility in mind when writing your tests
One of the most important points of RTL is accessibility and this is also a very important point for us. We should try our best to follow the RTL [Priority](https://testing-library.com/docs/queries/about/#priority) when querying for elements in our tests. `getByTestId` is not viewable by the user and should only be used when the element isn't accessible in any other way.
### Don't use `act` unnecessarily
`render` and `fireEvent` are already wrapped in `act`, so wrapping them in `act` again is a common mistake. Some solutions to the warnings related to `act` might be found [here](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning).
### Be specific when using *ByRole
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 })
```
Using the `name` property also avoids breaking the tests in the future if other components with the same role are added.
### userEvent vs fireEvent
Prefer the [user-event](https://github.com/testing-library/user-event) library, which provides a more advanced simulation of browser interactions than the built-in [fireEvent](https://testing-library.com/docs/dom-testing-library/api-events/#fireevent) method.
### Usage of waitFor
- [Prefer to use `find`](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#using-waitfor-to-wait-for-elements-that-can-be-queried-with-find) over `waitFor` when you're querying for elements. Even though both achieve the same objective, the `find` version is simpler and you'll get better error messages.
- Prefer to use only [one assertion at a time](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#having-multiple-assertions-in-a-single-waitfor-callback). If you put multiple assertions inside a `waitFor` we could end up waiting for the whole block timeout before seeing a test failure even if the failure occurred at the first assertion. By putting a single assertion in there, we can improve on test execution time.
- Do not perform [side-effects](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#performing-side-effects-in-waitfor) inside `waitFor`. The callback can be called a non-deterministic number of times and frequency (it's called both on an interval as well as when there are DOM mutations). So this means that your side-effect could run multiple times.
### Example
You can find an example of a test [here](https://github.com/apache/superset/blob/master/superset-frontend/src/dashboard/components/PublishedStatus/PublishedStatus.test.tsx).
## Cypress
### Prefer to use Cypress for e2e testing and RTL for integration testing
Here it's important to make the distinction between e2e and integration testing. This [article](https://www.onpathtesting.com/blog/end-to-end-vs-integration-testing) gives an excellent definition:
> End-to-end testing verifies that your software works correctly from the beginning to the end of a particular user flow. It replicates expected user behavior and various usage scenarios to ensure that your software works as whole. End-to-end testing uses a production equivalent environment and data to simulate real-world situations and may also involve the integrations your software has with external applications.
> A typical software project consists of multiple software units, usually coded by different developers. Integration testing combines those software units logically and tests them as a group.
> Essentially, integration testing verifies whether or not the individual modules or services that make up your application work well together. The purpose of this level of testing is to expose defects in the interaction between these software modules when they are integrated.
Do not use Cypress when RTL can do it better and faster. Many of the Cypress tests that we have right now, fall into the integration testing category and can be ported to RTL which is much faster and gives more immediate feedback. Cypress should be used mainly for end-to-end testing, replicating the user experience, with positive and negative flows.
### Isolated and standalone tests
Tests should never rely on other tests to pass. This might be hard when a single user is used for testing as data will be stored in the database. At every new test, we should reset the database.
### Cleaning state
Cleaning the state of the application, such as resetting the DB, or in general, any state that might affect consequent tests should always be done in the `beforeEach` hook and never in the `afterEach` one as the `beforeEach` is guaranteed to run, while the test might never reach the point to run the `afterEach` hook. One example would be if you refresh Cypress in the middle of the test. At this point, you will have built up a partial state in the database, and your clean-up function will never get called. You can read more about it [here](https://docs.cypress.io/guides/references/best-practices#Using-after-or-afterEach-hooks).
### Unnecessary use of `cy.wait`
- Unnecessary when using `cy.request()` as it will resolve when a response is received from the server
- Unnecessary when using `cy.visit()` as it resolves only when the page fires the load event
- 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)
```
### Accessibility and Resilience
The same accessibility principles in the RTL section apply here. Use accessible selectors when querying for elements. Those principles also help to isolate selectors from eventual CSS and JS changes and improve the resilience of your tests.
## References
- [Avoid Nesting when you're Testing](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing)
- [RTL - Queries](https://testing-library.com/docs/queries/about/#priority)
- [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)
- [Common mistakes with React Testing Library](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library)
- [ARIA Roles](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)
- [Cypress - Best Practices](https://docs.cypress.io/guides/references/best-practices)
- [End-to-end vs integration tests: what's the difference?](https://www.onpathtesting.com/blog/end-to-end-vs-integration-testing)