[WIP] Start updating JS parser unit tests #69
Conversation
|
@springmeyer Here's a draft of the kinds of tests I'm thinking + the way I was planning on including |
| import * as Path from "path"; | ||
| import { toBeDeepCloseTo, toMatchCloseTo } from "jest-matcher-deep-close-to"; | ||
| expect.extend({ toBeDeepCloseTo, toMatchCloseTo }); | ||
|
|
||
| const tilesDir = "./data"; | ||
|
|
||
| describe("CovtDecoder", () => { | ||
| it("should decode a simple valid tile", () => { | ||
| const tiles = getMvtFixtureTiles("017"); // Small valid MVT fixture |
There was a problem hiding this comment.
You could also do mvtFixtures.get('017') (https://github.com/mapbox/mvt-fixtures/blob/main/API.md#get)
There was a problem hiding this comment.
Yep! That's what I do below, I was using this method to try to stay aligned with how the other tile fetching happens in these tests (getting both the MVT and MLT at one time).
There was a problem hiding this comment.
Overall looking good / matches what I have had in mind. Great start.
One further idea: having the input mlt tiles generated dynamically. We could do this by having the JS tests call out to the java encoder CLI. Various pros/cons of doing this of course. Main cons are slowness and some potential brittleness. But the main benefits I see are: a) ensuring we are working with fresh/correct MLT tiles and not ones that are ever out of date or encoded with old java encoder bugs and b) then the JS tests will start failing (relevant once they are first passing) if the Java encoder changes in a way that is unexpected.
|
@ebrelsford another idea: considering having all test assertions be on JSON objects. We talked before about writing the tests to assert on each part of the decoded tile (which would be valuable for incrementally ensuring parts start working and for showing specifically what is failing to work). Still like this idea. But also, here is a quick alternative idea: to have the decoder create an entire GeoJSON in memory and then use a library like https://www.npmjs.com/package/json-diff to diff against an entire expected GeoJSON. This could accomplish the former goals with an additional benefit: as the tile fixtures grow increasingly complicated in terms of geometries we could then easily visualize by dumping the GeoJSON output to disk and tossing in a mapping program of choice. And of course the two approaches could be blended together. |
The intention of this PR is to update JS parser unit tests to test smaller parts of the code and with simpler input MVT/MLT tiles in order to make updating the parser more straightforward. It's expected that tests on this branch will fail until the parser is updated.