test: add basic LDtk faker types and use them LevelMetadataAccessor tests #238
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to have more comprehensive tests, but one obstacle in that respect has always been that the LDtk json types were very difficult to construct for tests. They are quite complicated and massive, so writing custom test data is very time consuming and difficult to maintain. This seems to me like a good use case for a faker library, so that is what this PR implements.
You may notice that these faker types are not very sophisticated, and only edit a few fields. My thoughts are that, as tests need to fake more fields of these types, they are welcome to improve the fakers. The sorts of things that are faked here are those that are used in tests for the new asset types. These fakers are also pretty careful about making the faked data a little bit realistic.. in particular, all faked levels will have the "same" set of layers with some per-instance variation much like a real LDtk file. At the highest level, there are also fakers for creating an LdtkJson with unloaded levels, and a separate list of loaded levels, which can be added to an asset store for testing of accessing external level data in the future.
I wasn't too careful about documenting these new types for now, since they are all behind
#[cfg(test)]
and do not appear in the library. If contributors find these types confusing, it may be worth documenting them in a future PR.