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.
Added test cases for these layouts
These will cover around 86 % of the code
Testing strategy :
There is one thing i know about unit tests, they should be concise, easy to read, easy to maintain, and they should easily give you an idea about what the library does !
the idea is Given an annotated DTO, we generate the ui Form, then we inspect the ui form to make sure that none of the informations specified in the annotations are missing.
There is 2 alternatives for this:
The JsonSchema object to test the customized json schema, and the JsonNode object to test the json schema ui form.
It is easy to fetch information from the JsonSchema object to make assertions, but the problem resides in the JsonNode object, it has a tree-like structure, and traversing trees often results in a complex code that is harder to maintain in the long run, and the more complex the json it represents, the more harder it will become to fetch an information out of it.
I found a quite popular library named json path, it has a query language like SQL to query json. the syntax is pretty easy to grasp. It also comes with helper classes for unit tests, to traverse json and make assertions.