Add comprehensive test suite infrastructure
- Create backend xUnit test project with Moq and FluentAssertions - Add test utilities: TestDataFactory, MockHttpContext, TestUserClaims - Create AuthControllerTests with comprehensive auth scenarios - Install Jest and React Testing Library for frontend - Configure jest.config.ts and jest.setup.ts with Next.js support - Add test scripts to package.json
This commit is contained in:
Denis Urs Rudolph
@@ -0,0 +1,37 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Backend test project exists
|
||||
The system SHALL have a dedicated .NET test project named `backend.Tests` that references the main `backend` project.
|
||||
|
||||
#### Scenario: Test project references main project
|
||||
- **WHEN** the test project is built
|
||||
- **THEN** it SHALL have a project reference to the main backend API project
|
||||
|
||||
### Requirement: Controllers can be unit tested
|
||||
The system SHALL provide the ability to unit test API Controllers with mocked dependencies.
|
||||
|
||||
#### Scenario: Controller with mocked service
|
||||
- **WHEN** a controller action is invoked with a mocked service
|
||||
- **THEN** the test SHALL verify the correct HTTP response is returned
|
||||
|
||||
#### Scenario: Controller input validation
|
||||
- **WHEN** invalid input is passed to a controller action
|
||||
- **THEN** the test SHALL verify validation errors are returned
|
||||
|
||||
### Requirement: Services can be unit tested
|
||||
The system SHALL provide the ability to unit test business logic in Services with mocked dependencies.
|
||||
|
||||
#### Scenario: Service with mocked repository
|
||||
- **WHEN** a service method is called with a mocked data repository
|
||||
- **THEN** the test SHALL verify the expected business logic is executed
|
||||
|
||||
### Requirement: Test utilities are available
|
||||
The system SHALL provide common test utilities for setup, teardown, and assertions.
|
||||
|
||||
#### Scenario: Mock data factories
|
||||
- **WHEN** tests require test data
|
||||
- **THEN** factory classes SHALL generate consistent mock entities
|
||||
|
||||
#### Scenario: HTTP context mocking
|
||||
- **WHEN** tests need to simulate HTTP requests
|
||||
- **THEN** utilities SHALL provide mocked HttpContext and User claims
|
||||
@@ -0,0 +1,49 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Jest is configured
|
||||
The system SHALL have Jest configured for the Next.js frontend with TypeScript support.
|
||||
|
||||
#### Scenario: Jest runs TypeScript tests
|
||||
- **WHEN** a test file with `.test.ts` or `.test.tsx` extension is executed
|
||||
- **THEN** Jest SHALL compile and run TypeScript tests successfully
|
||||
|
||||
#### Scenario: Jest runs in Next.js environment
|
||||
- **WHEN** tests import Next.js modules or use Next.js APIs
|
||||
- **THEN** the test environment SHALL provide necessary Next.js mocks and configuration
|
||||
|
||||
### Requirement: React Testing Library is configured
|
||||
The system SHALL have React Testing Library configured for component testing.
|
||||
|
||||
#### Scenario: Components can be rendered in tests
|
||||
- **WHEN** a React component is rendered using render() from RTL
|
||||
- **THEN** the component SHALL render in a virtual DOM for testing
|
||||
|
||||
#### Scenario: User interactions can be simulated
|
||||
- **WHEN** test code uses userEvent or fireEvent
|
||||
- **THEN** user interactions SHALL be simulated on rendered components
|
||||
|
||||
### Requirement: Custom hooks can be tested
|
||||
The system SHALL provide utilities for testing custom React hooks.
|
||||
|
||||
#### Scenario: Hook can be tested with renderHook
|
||||
- **WHEN** a custom hook is tested using renderHook utility
|
||||
- **THEN** the hook SHALL execute and return values can be asserted
|
||||
|
||||
#### Scenario: Hook state changes can be awaited
|
||||
- **WHEN** a hook performs async operations
|
||||
- **THEN** the test SHALL be able to wait for state updates with waitFor utility
|
||||
|
||||
### Requirement: API mocking is available
|
||||
The system SHALL provide utilities for mocking HTTP requests in frontend tests.
|
||||
|
||||
#### Scenario: API calls can be mocked
|
||||
- **WHEN** components make HTTP requests using fetch or axios
|
||||
- **THEN** the test SHALL be able to mock responses using MSW or jest-fetch-mock
|
||||
|
||||
#### Scenario: Loading states can be tested
|
||||
- **WHEN** components are fetching data
|
||||
- **THEN** the test SHALL verify loading states are rendered correctly
|
||||
|
||||
#### Scenario: Error states can be tested
|
||||
- **WHEN** API calls fail
|
||||
- **THEN** the test SHALL verify error handling and error messages
|
||||
@@ -0,0 +1,49 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Backend API integration tests exist
|
||||
The system SHALL have integration tests for the backend API that verify endpoints work correctly with real or test database.
|
||||
|
||||
#### Scenario: API endpoint returns expected response
|
||||
- **WHEN** an API endpoint is called via HTTP request
|
||||
- **THEN** the response SHALL match expected status code and body structure
|
||||
|
||||
#### Scenario: API endpoint persists data
|
||||
- **WHEN** a POST or PUT request is made
|
||||
- **THEN** the data SHALL be persisted and retrievable via GET request
|
||||
|
||||
#### Scenario: API handles authentication
|
||||
- **WHEN** a protected endpoint is called with or without valid authentication
|
||||
- **THEN** the response SHALL enforce authentication rules correctly
|
||||
|
||||
### Requirement: Frontend-backend integration tests exist
|
||||
The system SHALL have tests that verify the frontend can communicate with the backend API.
|
||||
|
||||
#### Scenario: Frontend fetches data from backend
|
||||
- **WHEN** the frontend makes an API call to the backend
|
||||
- **THEN** the backend SHALL receive the request and return appropriate data
|
||||
|
||||
#### Scenario: Frontend sends data to backend
|
||||
- **WHEN** the frontend submits form data to the backend
|
||||
- **THEN** the backend SHALL process the data and return success or error response
|
||||
|
||||
### Requirement: Test database is isolated
|
||||
The system SHALL use an isolated test database for integration tests.
|
||||
|
||||
#### Scenario: Test database is separate from development database
|
||||
- **WHEN** integration tests run
|
||||
- **THEN** they SHALL connect to a test database, not the development database
|
||||
|
||||
#### Scenario: Test database is reset between test runs
|
||||
- **WHEN** integration tests complete
|
||||
- **THEN** the test database state SHALL be cleaned up to ensure test isolation
|
||||
|
||||
### Requirement: Integration tests can run in CI
|
||||
The system SHALL support running integration tests in CI environment with test infrastructure.
|
||||
|
||||
#### Scenario: Backend and database start for tests
|
||||
- **WHEN** integration tests are executed in CI
|
||||
- **THEN** the backend and test database SHALL start automatically before tests
|
||||
|
||||
#### Scenario: Tests use correct environment configuration
|
||||
- **WHEN** tests run in CI environment
|
||||
- **THEN** they SHALL use CI-specific configuration (test database URLs, test auth secrets)
|
||||
@@ -0,0 +1,58 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: NPM scripts exist for test execution
|
||||
The system SHALL provide npm scripts to run different test suites.
|
||||
|
||||
#### Scenario: Run all tests
|
||||
- **WHEN** the command `npm test` or `npm run test` is executed
|
||||
- **THEN** all unit and integration tests SHALL execute
|
||||
|
||||
#### Scenario: Run backend tests only
|
||||
- **WHEN** the command `npm run test:backend` is executed
|
||||
- **THEN** only the backend unit tests SHALL run
|
||||
|
||||
#### Scenario: Run frontend tests only
|
||||
- **WHEN** the command `npm run test:frontend` is executed
|
||||
- **THEN** only the frontend unit tests SHALL run
|
||||
|
||||
#### Scenario: Run integration tests only
|
||||
- **WHEN** the command `npm run test:integration` is executed
|
||||
- **THEN** only the integration tests SHALL run
|
||||
|
||||
### Requirement: Tests run in watch mode for development
|
||||
The system SHALL support watch mode for iterative development.
|
||||
|
||||
#### Scenario: Watch mode runs tests on file changes
|
||||
- **WHEN** the command `npm run test:watch` is executed
|
||||
- **THEN** tests SHALL re-run automatically when source or test files change
|
||||
|
||||
#### Scenario: Watch mode can filter by test pattern
|
||||
- **WHEN** a test pattern is specified (e.g., `npm run test:watch -- Auth`)
|
||||
- **THEN** only matching tests SHALL run in watch mode
|
||||
|
||||
### Requirement: Gitea Actions workflow exists
|
||||
The system SHALL have a Gitea Actions workflow that runs tests on pull requests.
|
||||
|
||||
#### Scenario: Tests run on PR creation
|
||||
- **WHEN** a pull request is opened
|
||||
- **THEN** the Gitea Actions workflow SHALL trigger and run all tests
|
||||
|
||||
#### Scenario: Tests run on PR update
|
||||
- **WHEN** new commits are pushed to an open pull request
|
||||
- **THEN** the Gitea Actions workflow SHALL re-run tests
|
||||
|
||||
#### Scenario: PR is blocked on test failure
|
||||
- **WHEN** tests fail in the PR
|
||||
- **THEN** the PR SHALL show failed status and optionally block merging
|
||||
|
||||
#### Scenario: Backend tests run in CI
|
||||
- **WHEN** the CI workflow executes
|
||||
- **THEN** backend unit tests SHALL run after the project builds successfully
|
||||
|
||||
#### Scenario: Frontend tests run in CI
|
||||
- **WHEN** the CI workflow executes
|
||||
- **THEN** frontend unit tests SHALL run after dependencies are installed
|
||||
|
||||
#### Scenario: Integration tests run in CI
|
||||
- **WHEN** the CI workflow executes
|
||||
- **THEN** integration tests SHALL run with test infrastructure (backend + database) available
|
||||
Reference in New Issue
Block a user