Test data suit
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 3k
- Forks
- 196
- Avg merge
- 19h 2m
- Merged PRs (30d)
- 5
Description
It seems both Rust implementations of pmtiles got the spec wrong - based on my testing of pmtiles and pmtiles2 crates. I think the reason for that is that they both had to come up with their own test cases - thus obviously failing :)
In order to have the same behavior for all pmtiles implementations, we desperately need a standard set of test files that all implementations must pass (reminds me of the ACID browser tests.... memories...)
Anyway, could you standardize the tests by:
- consolidate all test data files in the https://github.com/protomaps/PMTiles/tree/main/js/test/data - or else it is unclear if they are the same or not? (I see some files in the
/jsdir) - create a readme in that same dir that points to the specific test code in one of the implementations (no point of describing the tests in the markdown, as i am sure it will quickly out of sync with the actual unit tests)
The reason for all this is that Martin tile server has received a great bug report https://github.com/maplibre/martin/issues/675 (thx @tobinbradley !) that highlights a bug, but I have no good way of converting that 200MB file into a useful pmtiles test file - so was hoping to find a test fixture here :)
Once again, thanks @bdon !
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting js/test/data and the other test-data files under /js, then compare them with the test code in the referenced pmtiles implementations and the Martin bug report. Consolidate the fixtures in js/test/data and add a README there linking to the specific implementation test code; done means the shared files and their authoritative test reference are clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- documentation, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100