Test data suit

[nyurik]

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 /js dir)
• 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 !

[bdon]

A lot of the low-level logic might fit unit tests better by standardizing the test cases used in this file:

https://github.com/protomaps/PMTiles/blob/main/js/test/v3.test.ts#L126

Because a directory is a flat list of elements we could potentially store it as a CSV file that each test suit reads for its data+assertions.

But yeah, I need to add at least one more complex integration testing file that has > 1 directory depth, which might be the root cause of the linked problem. While > 2 depth archives are allowed by the spec AFAIK there aren't any writers that make these (and I have yet to discover a realistic use case)

[nyurik]

yeah, perhaps we should have a simple utility to encode arbitrary complex JSON/YAML into protobuf, where the actual tile content is just a few bytes long. This way we can set up a yaml like this:

metadata:
  field: value
  field2: value2

dir:
  tiles:
    "0/0/0": "1"
    "0/0/1": "1"

(i am actually not certain about the dir/tiles structure - basically we need anything that would allow simple encoding of a tile by specifying its zxy coords plus content or same value as something else)