# Test Documentation

This document describes the automated tests implemented for the Home Monitor project. The tests are written with Cypress and are organized into two distinct categories: unit tests and end-to-end (E2E) tests.

## Test Types and Structure

The tests are organized in separate folders according to their type:

### 1. Unit Tests (`tests/unit/`)

Unit tests focus on testing individual components or classes in isolation, without dependencies on other parts of the system.

- **Example**: `Serie.spec.ts` - Tests the `Serie` class methods and functionality in isolation
- **Purpose**: Verify that individual components work correctly on their own
- **Characteristics**: Fast, focused, and test a single unit of code

### 2. End-to-End Tests (`tests/e2e/`)

E2E tests simulate real user scenarios by testing the entire application flow from start to finish.

- **Example**: `app.spec.ts` - Tests complete user workflows like navigating the application and interacting with charts
- **Purpose**: Verify that the entire application works as expected from a user's perspective
- **Characteristics**: Most comprehensive, test the entire system, slower than other test types

## Configuration

Tests use a custom configuration in `cypress.unit.js` that allows different test types to run with appropriate settings. Key features:

- Unit tests run without isolation (can share context)
- E2E tests run with isolation (fresh environment for each test)
- All tests can run without requiring a server (baseUrl is set to null)
- Optimized settings for performance (no videos, screenshots disabled by default)

## Running Tests

### Running Specific Test Types

```bash
# Run unit tests
npm run test:unit

# Run E2E tests
npm run test:e2e
```

### Running All Tests

```bash
npm run test
```

### Using Cypress GUI

To run tests through the Cypress graphical interface:

```bash
npm run cypress:open
```

This method is particularly useful during development, as it allows you to:
- View tests in real-time
- Inspect DOM elements
- Replay individual tests
- See a detailed overview of the executed steps

## Detailed Test Examples

### Unit Tests for Serie Class

The unit tests (`tests/unit/Serie.spec.ts`) verify that the Serie class works correctly in isolation:

- **Initialization**: Tests that the class initializes with the correct properties
- **Label Generation**: Tests that the `getLabel()` method returns the correct label based on series type
- **Data Formatting**: Tests that the `getSerie()` method correctly formats data for the chart library

### E2E Tests for Application

The E2E tests (`tests/e2e/app.spec.ts`) verify complete user workflows:

- **Application Loading**: Tests that the application loads correctly
- **Data Display**: Tests that temperature and humidity data are displayed properly
- **Filtering**: Tests that users can filter data by date range
- **Room Selection**: Tests that users can switch between different rooms
- **Error Handling**: Tests that errors are handled gracefully

## Test Data Structure

The tests use mock data in the following format:

```typescript
const mockData = [
  { time: 1625097600000, value: new Date(22.5) },
  { time: 1625184000000, value: new Date(23.8) }
];
```

Where:
- `time`: Unix timestamp in milliseconds
- `value`: Value encapsulated in a Date object (according to the current implementation)

## Special Note on Date Usage

The `Serie` class uses `Date` objects to store temperature and humidity values, which is a unique approach. In the test code, we create Date objects by directly passing the numeric values to the constructor:

```typescript
new Date(22.5)  // For a temperature of 22.5°C
new Date(45)    // For a humidity of 45%
```

This approach is specific to the current implementation of the `Serie` class and might be modified in the future to directly use numeric values.

## Best Practices

## Test Organization

1. **Test Hierarchy**: 
   - Unit tests -> E2E tests
   - Tests should get progressively more comprehensive
   - Most of your tests should be unit tests (faster and more focused)

2. **AAA Structure**: Tests follow the Arrange-Act-Assert pattern:
   - **Arrange**: Prepare test data and environment
   - **Act**: Execute the action being tested
   - **Assert**: Verify the expected results

3. **Isolation**: Each test should be independent and not depend on shared state

### Test Troubleshooting

If tests fail, check the following:

1. **Server Issues**: If you're running E2E tests that require a server, make sure it's started on the appropriate port

2. **API Changes**: If the classes or components are modified, tests must be updated accordingly

3. **Synchronization Issues**: Cypress might need additional time for certain operations

4. **Environment Issues**: Verify that all dependencies are installed with `npm install`

## Future Test Extensions

The current tests cover basic functionality. In the future, it would be useful to add:

1. More unit tests for all components and services
2. More comprehensive E2E tests covering all user scenarios
3. Performance tests for operations on large data sets