Config file refactoring & Json Config file support #690
Conversation
| public class BindingCultureConfigElement : ConfigurationElement | ||
| { | ||
| [ConfigurationProperty("name", DefaultValue = "en-US", IsRequired = false)] | ||
| [RegexStringValidator(@"\w{2}(-\w{2})?")] |
There was a problem hiding this comment.
This regex is too restrictive, see https://msdn.microsoft.com/en-us/goglobal/bb896001.aspx
There was a problem hiding this comment.
Oh. Just saw that it was done by me long time ago... :) It is fine then 😆 (just joking, we have to fix this, but maybe non in this PR.)
|
@gasparnagy |
|
@SabotageAndi The GeneratorConfiguration contains informations related to the generation phase (like allow row tests) and the RuntimeConfiguration contains things related to the runtime configuration (like tracing details). For some reason though, the generator also loads the RuntimeConfiguration, but I don't remember why this was needed (from the source code I don't see any good reason). |
|
Ok, that was also what I was thinking, but do we need this separation? |
|
@SabotageAndi i am fine merging it. (It is breaking change fro the plugins though.) At least we could make a spike to see if it causes any trouble. |
|
It would not be a SpecFlow release, if we do not change the plugin interface ;-) |
SabotageAndi
changed the title
|
@gasparnagy I think I am finished with this PR. |
There was a problem hiding this comment.
@SabotageAndi Please have a look at my comments. Most of them are general config rethik though...
| { | ||
| public class JsonConfigurationLoader | ||
| { | ||
| public SpecFlowConfiguration LoadJson(SpecFlowConfiguration specFlowConfiguration, string jsonContent) |
There was a problem hiding this comment.
The following configuration elements are obsolete or senseless, so I would not port them to the json (and remove them from the xml as well at some point -- or maybe keep it in the xml descriptor but remove them from the SpecFlowConfiguration/** classes).
- LanguageElement.Tool -- not used
- RuntimeElement.DetectAmbiguousMatches -- no point in setting it false
- GeneratorElement.GeneratorPath -- not used (at least I can't find any usage)
I am also unsure about RuntimeElement.MissingOrPendingStepsOutcome, but maybe someone uses that.
There was a problem hiding this comment.
Ok, I will remove them from Json and XML.
| } | ||
|
|
||
|
|
||
| return new SpecFlowConfiguration(ConfigSource.Json, |
There was a problem hiding this comment.
Are we sure about this huge constructor? Anyone who will use this class (e.g. for testing) will go crazy, because it will get broken every time when there is a small change in the config. I would go for the simple ctor (maybe with configSource) and set everything in properties.
There was a problem hiding this comment.
I was trying to make the configuration mutable. But somewhere it would take to much rewrite to support it, so I ended up again with public setters.
But with this constructor, every property has a defined value. And accessing the ConfigValues again in the constructor seems also to be ugly.
Any ideas which values should be used if I would use an empty constructor?
There was a problem hiding this comment.
We have defaults for everything, I think -- the settings we use in default configuration.
There was a problem hiding this comment.
Or just leave them empty. I don't know. But the ctor with so many params is not good...
|
|
||
| namespace TechTalk.SpecFlow.Configuration.JsonConfig | ||
| { | ||
| public class PluginEntry |
There was a problem hiding this comment.
All other are elements, except this one. I have found this confusing a bit.
|
|
||
| namespace TechTalk.SpecFlow.Configuration.JsonConfig | ||
| { | ||
| public class StepAssemblyEntry |
There was a problem hiding this comment.
See comment for the step assembly stuff
| public TraceElement Trace { get; set; } | ||
|
|
||
| [JsonProperty("stepAssemblies", NullValueHandling = NullValueHandling.Ignore)] | ||
| public List<StepAssemblyEntry> StepAssemblies { get; set; } |
There was a problem hiding this comment.
This is a badly named config in the app.config, and should be rather called as BindingAssemblies. I would probably use this name in the json already.
There was a problem hiding this comment.
I understand the reason to rename it, but it would mean that the config is different for XML and Json. I think this will irritate users. And we have to mention this in the documentation.
There was a problem hiding this comment.
I would also rename it in the app.config as a next step... it is anyway not used so broadly...
| { | ||
| [JsonProperty("name", DefaultValueHandling = DefaultValueHandling.Populate, NullValueHandling = NullValueHandling.Ignore)] | ||
| [DefaultValue("en-US")] | ||
| public string Name { get; set; } |
There was a problem hiding this comment.
Don't we want to move this under the language element and call it BindingCulture? I don't remember why we did this separation but i think it is senseless
| public class UnitTestProviderElement | ||
| { | ||
| [JsonProperty("name", NullValueHandling = NullValueHandling.Ignore)] | ||
| [DefaultValue("NUnit")] |
There was a problem hiding this comment.
I am thinking on not having any default for the unit test provider. It does not work with NUnit out of the box anyway (you have to add the nunit dependencies), so it would be more clean to force the user to specify something.
There was a problem hiding this comment.
Ok, this will break some stuff out in the wild.
How do we want to give the user feedback, that he has to configure something?
There was a problem hiding this comment.
Again, I would do this first only for the json. We can apply this to app.config as a next step.
Long term: if the unit test provider is not specified, the generator would throw an error, that would lead to an #error statement in the generated files -- the user will see this as compilation error
|
|
||
| configurationProvider.LoadConfiguration(runtimeConfiguration); | ||
| runtimePluginEvents.RaiseRegisterGlobalDependencies(container); | ||
|
|
||
| #if !BODI_LIMITEDRUNTIME |
There was a problem hiding this comment.
We had this IF because of silverlight, but I think it was because we had no config option for the dependencies. Maybe this is not necessary anymore. This would mean that we could put back the CustomDependencies to the json runtime/generator element.
Thinking about this more, I think it is good as it is. People should rather use plugins to reconf dependencies.
There was a problem hiding this comment.
Ok, but I will remove the compiler #if
| } | ||
|
|
||
| public RuntimeConfiguration RuntimeConfiguration { get; private set; } | ||
| public Configuration.SpecFlowConfiguration SpecFlowConfiguration { get; private set; } |
There was a problem hiding this comment.
Why do you have this "Configuration." prefixes? They seem to be unnecessary.
|
|
||
| namespace TechTalk.SpecFlow | ||
| { | ||
| public static class StringExtensions |
There was a problem hiding this comment.
We MUST NOT provide any public class that extends basic classes like "string", because this will add a strange impact for the user's projects. (There is such an error already with the ToIdentifier, but that is also wrong.)
If we really need this, we should make it internal, but I generally find it miseading to call a method "on" something that is null, so I don't like these in general...
string s = null;
s.IsNullOrEmpty(); //brrrrr....
There was a problem hiding this comment.
About public: you are right, i will make it internal.
Yes, it is unusual to write this, but I think, it is easier to read, because it forms nearly a sentence.
SabotageAndi
force-pushed
the
ConfigFile
branch
from
8a2dad0
to
83b6118
Compare
…nfig rename PrintConfigSource to TraceConfigSource
# Conflicts: # TechTalk.SpecFlow.Generator/Configuration/GeneratorConfiguration.cs # TechTalk.SpecFlow.Generator/Project/MsBuildProjectFileExtensions.cs # TechTalk.SpecFlow.Generator/Project/MsBuildProjectReader.cs # TechTalk.SpecFlow/Bindings/StepDefinitionRegexCalculator.cs # TechTalk.SpecFlow/Infrastructure/ContainerBuilder.cs # TechTalk.SpecFlow/Infrastructure/TestExecutionEngine.cs # TechTalk.SpecFlow/PlatformSpecific/ConfigurationSectionHandler.cs # Tests/TechTalk.SpecFlow.GeneratorTests/MsBuildProjectReaderTests.cs # Tests/TechTalk.SpecFlow.RuntimeTests/Infrastructure/TestExecutionEngineTests.cs # Tests/TechTalk.SpecFlow.RuntimeTests/RuntimeTests.csproj
|
@gasparnagy I updated this. |
|
@SabotageAndi would be very good to gave it in 2.2. |
|
If we want to integrate that, this has to be done for a major version and not a minor update. |
|
@SabotageAndi ok. then i do a quick re-review and merge this now. |
* update MSBuild.Community.Tasks to latest version via NuGet (SpecFlowOSS#801) * Regexless stepdef fixes (SpecFlowOSS#786) * Upgrade FluentAssertions * Add simple unit test * Add unit test for parametrized method * Add unit tests for regexless - 36 failing * fluent assertion does not allow { and } in the because part * refine expectations: shortening like "doesn't" should not work automatically * fix regexless matching issues * a bit more optimal solution that produces simpler regexes * Improve param locator * should not remove keywords from binding culture * small code improvements * refine expectations: should not allow whitespace or punctuation in the front of the step text (Given !foo) in order to make the generated regex faster (does not start with rule) * small refactor * update changelog, remove wip tags * add test for issue SpecFlowOSS#715 * Update changelog showing that SpecFlowOSS#301 is also fixed * add CI NuGet package feed * Added support for MsTest's [DeploymentItem] attribute with @mstest:DeploymentItem tag (SpecFlowOSS#805) * Added support for MsTest's [DeploymentItem] attribute with @Deploy tag (Issue SpecFlowOSS#803) * Prefixing new tag with `MsTest:` * using pascal case @mstest:DeploymentItem * wrapping nested using blocks with curly brackets * Change project reader from MSBuild to XML (SpecFlowOSS#837) * improve tests for project reader * add tests for new csproj format * change variable naming * complete read of classic projects * refactoring * mark not used properties as obsolete * support new project system & refactorings * use AppDomainIsolatedTask instead of Task to solve file looking issues with MsBuild * fix typo :-/ * add tests for linked files * Added display name for theory attribution (SpecFlowOSS#812) * Added display name for theory attribution * Fixed incorrect namespace reference to TheoryAttribute (no longer part of extensions) * Support context parameters on Before/After methods, FeatureContainer (SpecFlowOSS#779) * Added scenario: Inject FeatureContext into a BeforeFeature hook * first dummy implementation to make the scenario pass (runtime tests failing) * Use bindingInstanceResolver to resolve parameters * make unit tests pass * Add unit tests for what we have so far * support for resolving hook parameters from scenario context * better then step for the scenarios * fix unit test error * added failing test for resolving objects from feature container * refactor ScenarioContext * Implement FeatureContainer * move binding culture initialization to FeatureContext * fix featurecontext resolution from scenario container * Refactor scenario and feature context and remove displose hack that was necessary to avoid circular disposing loops * fix unit test failure * Make InternalContextManager to IObjectContainer reference more explicit * rename IBindingInstanceResolver to ITestObjectResolver (breaking change for some plugins) * Wildcard support for project reader (SpecFlowOSS#843) * Wildcard support for project reader * fix tests for AppVeyor * update changelog * Config file refactoring & Json Config file support (SpecFlowOSS#690) * split app.config elements to multiple files * make RuntimeConfiguration nearly immutable * extract config loading logic to RuntimeConfigurationLoader * reformating * add tests for app.config reading * move ConfigurationTest to separate Namespace * rename file * add json tests * add json.net dependency * json config file parsing * add tests for checking which config file is used * refactoring for tests and added tests * remove GeneratorConfiguration * fix dependencies for generator * fix tests * fix tests * move files & fix namespaces * work on generation config loading * fix tests and make parsing more robust * fix and comment test * small cleanups * remove ToolLanguage, GeneratorPath and DetectAmbiguousMatches from Config rename PrintConfigSource to TraceConfigSource * fix merge issues * remove file * add missing json handling * update changelog * add Newtonsoft.Json dependency to the NuGet package * update TestGenerator version * fix typo in README.md (SpecFlowOSS#853) * fix VS code behind generation (SpecFlowOSS#855) * fix redirects * fix serialization problem with Visual Studio * fix lineending * Order sensitive overload for compare to set (SpecFlowOSS#778) * Add tests * Refactor TableDifferenceResults to be able to represent order sensitive diff * make throw tests pass * refactor message tests to be able to test order sensitive comparison * fix diff messages for order sensitive * Replace Tuple with TableDifferenceItem * Hook with multiple Tags scoped are executed more than once (SpecFlowOSS#848) * add failing tests * Fix for SpecFlowOSS#848 Hook with multiple Tags scoped are executed more than once * making sure that the ordering is preserved (the GroupBy might change the order) * update changelog for 2.2.0-prerelease20170523 * add GitExtensions configuration file with github and appveyor configuration (SpecFlowOSS#862) * Added TestThreadContext and exposed it in ContextManager and Steps base class (SpecFlowOSS#875) * Added TestThreadContext and exposed it in ContextManager and Steps base class * Upgrade to BoDi v1.3 (SpecFlowOSS#876) * fix shadow copy test issue * upgrade BoDi to v1.3 * remove unnecessary BoDi workarounds * Adds support for xUnit2 ITestOutputHelper SpecFlowOSS#575 (SpecFlowOSS#874) * Resolves SpecFlowOSS#575 * added tests for adding support for xUnit2 ITestOutputHelper class added XUnit2Generator unit tests added XUnit2Provider specs updated XUnitExecutionDriver to output results in default (xUnit) xml output instead of NUnit xml format * swapped the order of the TestInitialize call and the setting of the _testOutputHelper field * expose TestAssembly and BindingAssemblies on ITestRunnerManager * Fix generation from visual studio (SpecFlowOSS#877) * rename field so that it matches the version of this class from 1.9 (which is used by VS) * make AppConfig the default value * add warnings * Update for 2.2 release * use FileStream constructor which grants ReadWrite to other processes. (SpecFlowOSS#906) use FileStream constructor which grants ReadWrite to other processes SpecFlowOSS#904 * Added changelog entry for PR (SpecFlowOSS#907) * correct version number * Access MSTest's TestContext property via ScenarioContext (SpecFlowOSS#882) * injected MSTest's TestContext into ScenarioContext * fixed TestContext property generation for VB.Net * @MSBuild [DeploymentItem] - added option to provide output directory (SpecFlowOSS#901) * @MSBuild [DeploymentItem] - added option to provide output directory * code review * update changelog after merging PRs SpecFlowOSS#882 & SpecFlowOSS#901 * add tests for Feature/Scenario Hooks with context parameters (SpecFlowOSS#925) * Issue Template (SpecFlowOSS#924) * Create issue template * add SpecFlow+Runner to test runners * Rename issue to ISSUE_TEMPLATE.md * Allowed custom XSLT scripts to contain scripts. * Updated changelog for new addition * enter release date * fix changelog after 2.2.1 release * added link to Stack Overflow repro topic (SpecFlowOSS#942) * Avoid trying to load empty configuration * Set ConfigSource of default holder to "Default" instead of "AppConfig" * Turn off line ending git auto conversion (SpecFlowOSS#953) * Stop git from automatically converting line endings everytime repo is cloned * add .vs folder to .gitignore * Fixing copy link in step definition report (SpecFlowOSS#958) * Update changelog * Support for tuples (SpecFlowOSS#951) * Initial support for Tuples * Adding nuspec dependency * Added tupple error when there are too many properties * add entry for tuple * Make scenario TestResult public (SpecFlowOSS#963) * Make scenario TestResult public * - Rename to ScenarioExecutionStatus - Moved this to the root of the project - UndefinedStep in enum - Edited changelog.txt * Update changelog.txt * Single agent for unit tests execution * Fix incorrect appveyour config * Try to change test_script to test * Disable automatic tests * Provide full path to test assemblies * Expose configuration var to batch * Hardcoded configuration as Release * Use %% accessor for configuration var * Add hyperlink to discussion group (SpecFlowOSS#965) Remove ambiguity regarding where to go for questions.
No description provided.