Add a test extension dedicated to testing configuration #945
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dmlloyd
approved these changes
Feb 19, 2019
There was a problem hiding this comment.
The behavior we want for non-Optional, non-List Object fields with no default value is usually (probably always) to initialize it to null. I have most of a patch to fix that, which I can hopefully finish today.
Getting the test extension committed sooner is more important than fixing every problem that might arise from it, so if there are tests that fail, let's just @Ignore them and open issues for each.
|
Ok, let me do some cleanup on this and then it can be merged. |
|
I guess it can be merged now. The test is disabled due to #959. |
Add fix for #978
gsmet
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Here is an initial stab at creating a test-extension in the core module. There are a couple of things I'm not sure of:
I'm validating the TestBuildTimeConfig and TestRunTimeConfig config roots in the TestTemplate#checkConfig build step. I was expecting that the TestRunTimeConfig fields would not have been set since it uses ConfigPhase.RUN_TIME. Currently that check is commented out since it fails. What am I missing here about how ConfigPhase.RUN_TIME behaves?
During the initialization phase of configuration, all config object fields are initialized to their given default or some type specific default. I have added a mapDefaultValue utility method to allow for the ObjectConfigType to provide a better choice than an empty string based on the fieldClass. This addresses the problem of Improve error reporting of missing default config values #891. I see Empty configuration values are passed to the converter #877 regarding empty string values passed to the converters. The question I have is why are we trying to initialize non-defaulted fields?