File: TESTING.md

package info (click to toggle)
python-wrapt 2.1.1-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental
  • size: 1,592 kB
  • sloc: python: 8,452; ansic: 2,978; makefile: 168; sh: 46
file content (239 lines) | stat: -rw-r--r-- 8,046 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
# Testing Guide

This document explains how to run tests for the wrapt project and the conventions used for Python version-specific test files.

## Test Directory Structure

The `tests/core/` directory contains all test files for the wrapt project. Test files follow these conventions:

- **Standard test files**: `test_*.py` - These run on all supported Python versions
- **Python version-specific test files**: `test_*_pyXX.py` - These only run on specific Python versions or later

## Python Version-Specific Test Files

The project uses a special naming convention to ensure certain tests only run on appropriate Python versions. This is handled automatically by the `tests/conftest.py` configuration.

### Naming Convention

Test files can include version suffixes to indicate minimum Python version requirements:

- `test_name_py3.py` - Runs only on Python 3.x (skipped on Python 2.x)
- `test_name_py2.py` - Runs only on Python 2.x (skipped on Python 3.x)
- `test_name_py36.py` - Runs only on Python 3.6 and later
- `test_name_py37.py` - Runs only on Python 3.7 and later
- `test_name_py38.py` - Runs only on Python 3.8 and later

### Examples in the Codebase

- `test_class_py37.py` - Tests class-related features that require Python 3.7+
- `test_descriptors_py36.py` - Tests descriptor features that require Python 3.6+
- `test_inheritance_py37.py` - Tests inheritance features that require Python 3.7+
- `test_adapter_py33.py` - Tests adapter features that require Python 3.3+ (keyword-only arguments)

### How It Works

The `tests/conftest.py` file contains a `pytest_pycollect_makemodule` hook that:

1. Parses the filename for version patterns using regex: `_py(\d)(\d*)`
2. Compares the detected version requirement with the current Python version
3. Returns a dummy collector (skips the test) if the current version is too old
4. Allows normal test collection if the version requirement is met

## Running Tests

The project provides several ways to run tests using the `just` command runner.

### Available Test Commands

#### Run All Tests
```bash
just test
```
This runs the complete test suite across all supported Python versions (3.9-3.14). For each version, it tests three scenarios:
1. Without C extensions
2. With C extensions
3. With C extensions disabled at runtime

#### Test Specific Python Version
```bash
just test-version 3.13
```
Replace `3.13` with any supported Python version (3.9, 3.10, 3.11, 3.12, 3.13, 3.14).

#### Legacy Test Runner (using tox)
```bash
just test-tox
```
Runs tests using the traditional tox configuration.

#### Simple Test Run (backward compatibility)
```bash
just test-pip
```
Runs tests using pip-installed pytest in the main virtual environment.

#### Type Checking with mypy
```bash
just test-mypy
```
Runs mypy type checking across all supported Python versions (3.9-3.14).

```bash
just test-mypy-version 3.13
```
Runs mypy type checking for a specific Python version. Replace `3.13` with any supported version.

### Test Variants

Each `test-version` run includes three important test scenarios:

1. **Without C Extensions** (`WRAPT_INSTALL_EXTENSIONS=false`)
   - Tests the pure Python implementation
   - Ensures the fallback code works correctly

2. **With C Extensions** (`WRAPT_INSTALL_EXTENSIONS=true`)
   - Tests the optimized C implementation
   - Verifies performance-critical paths

3. **C Extensions Disabled at Runtime** (`WRAPT_DISABLE_EXTENSIONS=true`)
   - Tests the ability to disable C extensions after installation
   - Useful for debugging and compatibility testing

### Environment Variables

- `WRAPT_INSTALL_EXTENSIONS=true/false` - Controls whether C extensions are built during installation
- `WRAPT_DISABLE_EXTENSIONS=true/false` - Controls whether C extensions are used at runtime

## Mypy Type Checking Tests

The project includes custom pytest handlers for testing mypy type checking behavior. These tests ensure that the wrapt library's type annotations work correctly and produce expected mypy error messages. Note that `mypy` must exist in your `PATH` else the tests related to type checking which be skipped.

### Test File Convention

Mypy tests follow a specific naming pattern in the `tests/mypy/` directory:

- **Test files**: `mypy_*.py` - Python files containing code to be type-checked
- **Expected output files**: `mypy_*.out` - Files containing the expected mypy output

### How Mypy Tests Work

The custom test handler in `conftest.py` automatically discovers pairs of `mypy_*.py` and `mypy_*.out` files and:

1. Runs `mypy --show-error-codes --python-version X.Y` on the `.py` file
2. Compares the actual output with the expected output in the `.out` file
3. Fails the test if the outputs don't match

These tests only run on Python 3.9+ to ensure consistent mypy behavior.

### Creating New Mypy Tests

To create a new mypy test case:

1. **Create the test file**: Write a Python file with the code you want to type-check:
   ```bash
   # Create tests/mypy/mypy_your_test_name.py
   ```

2. **Review output from test**: Review the test output to ensure it contains the expected error messages and type information:
   ```bash
   just view-mypy-test mypy_your_test_name
   ```

3. **Save the expected output**: Run mypy to capture the expected output, by running:
   ```bash
   just save-mypy-test mypy_your_test_name
   ```

3. **Verify the output**: Check the output from running the test against expected output, by running: 
   ```bash
   just check-mypy-test mypy_your_test_name
   ```

4. **Run the test**: The test will automatically be discovered and run with pytest:
   ```bash
   uv run pytest tests/ -k mypy_your_test_name
   ```

### Example

The existing `mypy_function_wrapper.py` test demonstrates type checking for `FunctionWrapper`:

```python
from wrapt import FunctionWrapper

def f(a: bool, b: str) -> int:
    return 1

def standard_wrapper(wrapped, instance, *args, **kwargs):
    pass

f1 = FunctionWrapper(f, standard_wrapper)
reveal_type(f1)  # Should reveal the original function's type

result1a: int = f1(True, "test")     # Valid usage
result1b: str = f1(1, None)         # Invalid usage - should error
```

The corresponding `mypy_function_wrapper.out` file contains the expected mypy output, including:
- Type revelation notes
- Assignment errors
- Argument type errors
- Error codes for each issue

This approach ensures that the wrapt library's type annotations behave consistently and provide helpful error messages to users.

## Development Workflow

### Testing During Development

For quick testing during development, you can:

1. Run all tests against all Python versions:
   ```bash
   just test
   ```

2. Test a specific Python version you're working with:
   ```bash
   just test-version 3.11
   ```

3. Run legacy tests if needed:
   ```bash
   just test-tox
   ```

4. Run type checking across all Python versions:
   ```bash
   just test-mypy
   ```

5. Run type checking for a specific Python version:
   ```bash
   just test-mypy-version 3.11
   ```

### Adding New Tests

When adding new test files:

1. **Standard unit tests**: Use the `test_*.py` naming convention for general tests
2. **Version-specific tests**: Use the `test_*_pyXX.py` convention if your test requires features from a specific Python version
3. **Mypy type tests**: Use the `mypy_*.py` naming convention for type checking tests (see the Mypy Type Checking Tests section above)
4. The version detection is automatic - no additional configuration needed

### Test Dependencies

Test dependencies are managed in `pyproject.toml`. The main requirements are:
- `pytest` - For running unit tests

If running `tox` or `mypy` tests, it is assumed that these are installed as a tool using `uv tool install` command (or any other available method) and available in your `PATH`.

## Continuous Integration

The project uses GitHub Actions for automated testing. Tests are triggered on:
- Release tags
- Pull requests
- Workflow dispatch

The CI system runs the full test suite across all supported Python versions and platforms.