This repository has been archived by the owner on Nov 27, 2023. It is now read-only.
#3 - Base test case for support for collections and maps #7
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.
Base test cases for #3 - Ability to override List/Set/Map property.
As there are many cases functional testing all of them with nebula-test plugin would be an overkill. I left 2 simple cases and moved other to unit/integration tests. The implementation would probably require to extract a mechanism from
DotNotationWalkerOverrideStrategy
to determine a field type (also a generic type for collections - likefoo.class.declaredFields[0].getGenericType()
) and leave only base types forApacheCommonsTypeConverter
. Therefore I left test in a very generic form.I am not also sure about the name. ComplexType can suggest that complex/custom type can be passed. Collections and Maps is an alternative.
Probably not all test cases should be supported - to make the implementation easier. Also there are for sure cases I missed.
Regarding
def
as extension is exposed API I would consider the lack of support for fields defined asdef
or use specific default behavior which to cover only base cases (the easier way).If you decide to keep so many test cases the duplication in
where:
part could be eliminated with some Groovy tricks onpropertyName
column.