This guide covers development setup, testing, code quality, and contribution guidelines for the WiFiScan Collector.
- Python 3.13+
- Git
- Linux system with wireless capabilities
iwtool installed
-
Clone the repository:
git clone https://github.com/lux4rd0/wifiscan-collector.git cd wifiscan-collector -
Create virtual environment:
python3.13 -m venv venv source venv/bin/activate -
Install dependencies:
pip install -r requirements.txt pip install -r requirements-dev.txt
-
Configure environment:
cp .env.example .env # Edit .env with your settings
The project enforces strict code quality standards using multiple tools:
- Black: Code formatter with 88-character line limit
- isort: Import sorting (integrated with Black)
- Ruff: Fast Python linter (replaces flake8, pylint, isort)
- Flake8: Additional style checking
- MyPy: Static type checking
Run all quality checks:
# Format code
black src/ tests/
# Check linting
ruff check src/ tests/
# Check style
flake8 src/ tests/
# Check types
mypy src/ --ignore-missing-importsOr run everything at once:
black src/ tests/ && ruff check src/ tests/ && flake8 src/ tests/ && mypy src/ --ignore-missing-importsInstall pre-commit hooks to automatically run quality checks:
pip install pre-commit
pre-commit installtests/
├── conftest.py # Pytest configuration and fixtures
├── test_config.py # Configuration tests
├── test_models.py # Data model tests
├── test_scanner.py # WiFi scanner tests
├── test_storage.py # InfluxDB storage tests
└── test_utils.py # Utility function tests
Run all tests:
pytest -vRun with coverage:
pytest -v --cov=src --cov-report=term-missingRun specific test file:
pytest tests/test_scanner.py -vRun specific test:
pytest tests/test_scanner.py::TestWifiScanner::test_parse_iw_output -vThe project maintains high test coverage across all modules:
- Configuration validation
- WiFi network parsing
- InfluxDB storage operations
- Circuit breaker functionality
- Interface discovery
- Utility functions
- Use pytest fixtures for common setup
- Test both success and failure scenarios
- Mock external dependencies (InfluxDB, subprocess calls)
- Include edge cases and error conditions
- Follow naming convention:
test_function_name_scenario
src/
├── wifiscan-collector.py # Entry point wrapper
└── wifiscan_collector/
├── __init__.py # Package initialization
├── config.py # Pydantic configuration models
├── main.py # Application entry point
├── models.py # Data models (WifiNetwork)
├── scanner.py # WiFi scanning logic
├── storage.py # InfluxDB storage handler
├── utils.py # Utility functions
└── version.py # Version detection
tests/
├── conftest.py # Pytest configuration
├── test_config.py # Configuration tests
├── test_models.py # Model tests
├── test_scanner.py # Scanner tests
├── test_storage.py # Storage tests
└── test_utils.py # Utility tests
docs/
├── development.md # This file
├── configuration.md # Detailed configuration guide
└── troubleshooting.md # Extended troubleshooting guide
- Follow PEP 8 with 88-character line limit
- Use type hints for all functions and methods
- Use docstrings for all public functions
- Prefer
pathliboveros.path - Use f-strings for string formatting
- Use
async/awaitfor I/O operations - Use
asyncio.create_subprocess_execfor subprocess calls - Properly handle
asyncio.CancelledError - Use context managers for resource cleanup
- Use specific exception types
- Log errors with appropriate levels
- Sanitize sensitive data in error messages
- Include context in error messages
- Test async functions with
@pytest.mark.asyncio - Use
unittest.mockfor mocking - Test both success and failure paths
- Use descriptive test names
The project uses Pydantic for configuration management:
- Add field to
Configclass inconfig.py - Include default value and description
- Add validation if needed
- Update
.env.example - Add tests in
test_config.py - Update documentation
All configuration uses the WIFISCAN_COLLECTOR_ prefix:
- Use uppercase for environment variables
- Use lowercase for Python field names
- Include type hints and descriptions
- Provide sensible defaults
- Fork the repository
- Create a feature branch:
git checkout -b feature/amazing-feature - Make your changes
- Run all quality checks (formatting, linting, type checking)
- Run the test suite and ensure all tests pass
- Update documentation if needed
- Commit your changes:
git commit -m 'Add amazing feature' - Push to the branch:
git push origin feature/amazing-feature - Open a Pull Request
- Use present tense ("Add feature" not "Added feature")
- Use imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit first line to 72 characters
- Reference issues and pull requests liberally
- All changes require code review
- Address all review comments
- Ensure CI passes before merging
- Squash commits when merging
- Update version in directory structure (2025/7/x)
- Update CHANGELOG.md
- Run full test suite
- Create release tag
- Build and push Docker image
- Update documentation
Enable debug logging:
export WIFISCAN_COLLECTOR_LOG_LEVEL=DEBUG- Import errors: Ensure virtual environment is activated
- Test failures: Check for proper mocking of external dependencies
- Type errors: Run
mypy src/to check type annotations - Format errors: Run
black src/ tests/to fix formatting
Test interface manually:
# Check interface status
ip link show wlan0
# Test scanning
sudo iw dev wlan0 scan | head -20Use InfluxDB CLI to verify data:
influx query 'from(bucket:"wifiscan") |> range(start: -1h) |> limit(n:10)'- Monitor buffer size during development
- Test with various buffer limits
- Profile memory usage during long runs
- Scan interval affects CPU usage
- Parsing is CPU-intensive for large scan results
- Consider batch processing for performance
- Batch size affects network traffic
- Circuit breaker prevents network flooding
- Monitor InfluxDB write performance
- Never commit secrets to version control
- Use environment variables for configuration
- Sanitize tokens in error messages
- Use secure defaults
- Regularly update dependencies
- Review security advisories
- Use dependency scanning tools
- Pin versions in requirements.txt
- Use docstrings for all public functions
- Include parameter and return types
- Document exceptions that can be raised
- Include usage examples
- Keep README.md user-focused
- Provide comprehensive configuration examples
- Include troubleshooting guides
- Update documentation with new features
- Check existing issues before creating new ones
- Include full error messages and logs
- Provide system information (OS, Python version)
- Include configuration (without sensitive data)