The current test suite for ucd-store mostly uses mocked APIs and file systems, which is great for unit testing but doesn't catch integration issues that happen when the store actually talks to a real API and writes to a real filesystem.
We need a proper e2e test suite that:
- Uses the actual UCD API (or a test instance)
- Writes to a real temporary directory
- Tests complete workflows from start to finish
- Verifies that all the pieces work together correctly
The e2e tests should cover real-world scenarios like:
- Initializing a fresh store and downloading Unicode data
- Running mirror operations that actually fetch files from the API
- Analyzing a store to find missing or orphaned files
- Cleaning up a store by removing extra files
- Repairing a store that has corrupted data
- Using different filesystem bridges (node, http, memory) in realistic ways
- Handling errors when the API is down or returns unexpected data
These tests would run slower than unit tests but would give us confidence that the store actually works when you point it at the real API and filesystem. They'd catch issues like:
- URL construction bugs that mocks don't reveal
- File path issues on different operating systems
- Edge cases in the API responses
- Race conditions in concurrent operations
- Memory issues with large datasets
The e2e tests should probably be in their own test files (like store.e2e.test.ts) and potentially skipped in CI or run less frequently, since they depend on external services and take longer to run.
The current test suite for
ucd-storemostly uses mocked APIs and file systems, which is great for unit testing but doesn't catch integration issues that happen when the store actually talks to a real API and writes to a real filesystem.We need a proper e2e test suite that:
The e2e tests should cover real-world scenarios like:
These tests would run slower than unit tests but would give us confidence that the store actually works when you point it at the real API and filesystem. They'd catch issues like:
The e2e tests should probably be in their own test files (like
store.e2e.test.ts) and potentially skipped in CI or run less frequently, since they depend on external services and take longer to run.