New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config file refactoring & Json Config file support #690

Merged
merged 26 commits into from May 5, 2017

Conversation

Projects
None yet
2 participants
@SabotageAndi
Collaborator

SabotageAndi commented Aug 4, 2016

No description provided.

Show outdated Hide outdated TechTalk.SpecFlow/PlatformSpecific/AppConfig/BindingCultureConfigElement.cs
public class BindingCultureConfigElement : ConfigurationElement
{
[ConfigurationProperty("name", DefaultValue = "en-US", IsRequired = false)]
[RegexStringValidator(@"\w{2}(-\w{2})?")]

This comment has been minimized.

@gasparnagy

gasparnagy Aug 15, 2016

Collaborator

This regex is too restrictive, see https://msdn.microsoft.com/en-us/goglobal/bb896001.aspx

This comment has been minimized.

@gasparnagy

gasparnagy Aug 15, 2016

Collaborator

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

gasparnagy Aug 15, 2016

Collaborator

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.)

@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
Collaborator

SabotageAndi commented Aug 17, 2016

@gasparnagy

This comment has been minimized.

Show comment
Hide comment
@gasparnagy

gasparnagy Aug 17, 2016

Collaborator

@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).

Collaborator

gasparnagy commented Aug 17, 2016

@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).

@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
@SabotageAndi

SabotageAndi Aug 17, 2016

Collaborator

Ok, that was also what I was thinking, but do we need this separation?
I would like to merge this two together. This would remove some duplicate code.

Collaborator

SabotageAndi commented Aug 17, 2016

Ok, that was also what I was thinking, but do we need this separation?
I would like to merge this two together. This would remove some duplicate code.

@gasparnagy

This comment has been minimized.

Show comment
Hide comment
@gasparnagy

gasparnagy Aug 17, 2016

Collaborator

@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.

Collaborator

gasparnagy commented Aug 17, 2016

@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.

@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
@SabotageAndi

SabotageAndi Aug 17, 2016

Collaborator

It would not be a SpecFlow release, if we do not change the plugin interface ;-)

Collaborator

SabotageAndi commented Aug 17, 2016

It would not be a SpecFlow release, if we do not change the plugin interface ;-)

@SabotageAndi SabotageAndi changed the title from [WIP] Config file refactoring & Json Config file support to Config file refactoring & Json Config file support Oct 30, 2016

@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
@SabotageAndi

SabotageAndi Oct 30, 2016

Collaborator

@gasparnagy I think I am finished with this PR.
Could you have a look at it please?

Collaborator

SabotageAndi commented Oct 30, 2016

@gasparnagy I think I am finished with this PR.
Could you have a look at it please?

@gasparnagy

@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)

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 4, 2016

Collaborator

Ok, I will remove them from Json and XML.

@SabotageAndi

SabotageAndi Dec 4, 2016

Collaborator

Ok, I will remove them from Json and XML.

}
return new SpecFlowConfiguration(ConfigSource.Json,

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 4, 2016

Collaborator

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?

@SabotageAndi

SabotageAndi Dec 4, 2016

Collaborator

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?

This comment has been minimized.

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

We have defaults for everything, I think -- the settings we use in default configuration.

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

We have defaults for everything, I think -- the settings we use in default configuration.

This comment has been minimized.

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

Or just leave them empty. I don't know. But the ctor with so many params is not good...

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

Or just leave them empty. I don't know. But the ctor with so many params is not good...

Show outdated Hide outdated TechTalk.SpecFlow/Configuration/JsonConfig/PluginEntry.cs
namespace TechTalk.SpecFlow.Configuration.JsonConfig
{
public class PluginEntry

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

All other are elements, except this one. I have found this confusing a bit.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

All other are elements, except this one. I have found this confusing a bit.

Show outdated Hide outdated TechTalk.SpecFlow/Configuration/JsonConfig/StepAssemblyEntry.cs
namespace TechTalk.SpecFlow.Configuration.JsonConfig
{
public class StepAssemblyEntry

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

See comment for the step assembly stuff

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

See comment for the step assembly stuff

Show outdated Hide outdated TechTalk.SpecFlow/Configuration/JsonConfig/SpecFlowElement.cs
public TraceElement Trace { get; set; }
[JsonProperty("stepAssemblies", NullValueHandling = NullValueHandling.Ignore)]
public List<StepAssemblyEntry> StepAssemblies { get; set; }

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

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.

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

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.

This comment has been minimized.

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

I would also rename it in the app.config as a next step... it is anyway not used so broadly...

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

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; }

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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")]

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

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?

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

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?

This comment has been minimized.

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

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

@gasparnagy

gasparnagy Dec 7, 2016

Collaborator

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

Show outdated Hide outdated TechTalk.SpecFlow/Infrastructure/ContainerBuilder.cs
configurationProvider.LoadConfiguration(runtimeConfiguration);
runtimePluginEvents.RaiseRegisterGlobalDependencies(container);
#if !BODI_LIMITEDRUNTIME

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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.

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

Ok, but I will remove the compiler #if

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

Ok, but I will remove the compiler #if

Show outdated Hide outdated TechTalk.SpecFlow/Plugins/RuntimePluginEventArgs.cs
}
public RuntimeConfiguration RuntimeConfiguration { get; private set; }
public Configuration.SpecFlowConfiguration SpecFlowConfiguration { get; private set; }

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

Why do you have this "Configuration." prefixes? They seem to be unnecessary.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

Why do you have this "Configuration." prefixes? They seem to be unnecessary.

Show outdated Hide outdated TechTalk.SpecFlow/StringExtensions.cs
namespace TechTalk.SpecFlow
{
public static class StringExtensions

This comment has been minimized.

@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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....
@gasparnagy

gasparnagy Nov 30, 2016

Collaborator

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....

This comment has been minimized.

@SabotageAndi

SabotageAndi Dec 6, 2016

Collaborator

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

SabotageAndi Dec 6, 2016

Collaborator

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 added some commits May 4, 2017

Merge branch 'master' into ConfigFile
# 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
@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
@SabotageAndi

SabotageAndi May 4, 2017

Collaborator

@gasparnagy I updated this.
Do we want it in 2.2 or later? I want to make a prerelease of 2.2 next week and if nothing bad happens will release the version 1 week afterwards.

Collaborator

SabotageAndi commented May 4, 2017

@gasparnagy I updated this.
Do we want it in 2.2 or later? I want to make a prerelease of 2.2 next week and if nothing bad happens will release the version 1 week afterwards.

@gasparnagy

This comment has been minimized.

Show comment
Hide comment
@gasparnagy

gasparnagy May 5, 2017

Collaborator

@SabotageAndi would be very good to gave it in 2.2.
The only thing that I was thinking about is the config abstraction Werner mentioned... But I know nothing about it yet...

Collaborator

gasparnagy commented May 5, 2017

@SabotageAndi would be very good to gave it in 2.2.
The only thing that I was thinking about is the config abstraction Werner mentioned... But I know nothing about it yet...

@SabotageAndi

This comment has been minimized.

Show comment
Hide comment
@SabotageAndi

SabotageAndi May 5, 2017

Collaborator

If we want to integrate that, this has to be done for a major version and not a minor update.
Too much stuff could break. If it happens on a major version, I have not that problem with breaking stuff.

Collaborator

SabotageAndi commented May 5, 2017

If we want to integrate that, this has to be done for a major version and not a minor update.
Too much stuff could break. If it happens on a major version, I have not that problem with breaking stuff.

@gasparnagy

This comment has been minimized.

Show comment
Hide comment
@gasparnagy

gasparnagy May 5, 2017

Collaborator

@SabotageAndi ok. then i do a quick re-review and merge this now.

Collaborator

gasparnagy commented May 5, 2017

@SabotageAndi ok. then i do a quick re-review and merge this now.

@gasparnagy gasparnagy merged commit 1abd32a into techtalk:master May 5, 2017

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

Autom8edChaos added a commit to Autom8edChaos/SpecFlow that referenced this pull request Nov 6, 2017

Update from original (#1)
* update MSBuild.Community.Tasks to latest version via NuGet (#801)

* Regexless stepdef fixes (#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 #715

* Update changelog showing that #301 is also fixed

* add CI NuGet package feed

* Added support for MsTest's [DeploymentItem] attribute with @mstest:DeploymentItem tag (#805)

* Added support for MsTest's [DeploymentItem] attribute with @deploy tag (Issue #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 (#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 (#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 (#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 (#843)

* Wildcard support for project reader
* fix tests for AppVeyor

* update changelog

* Config file refactoring & Json Config file support (#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 (#853)

* fix VS code behind generation (#855)

* fix redirects
* fix serialization problem with Visual Studio
* fix lineending

* Order sensitive overload for compare to set (#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 (#848)

* add failing tests
* Fix for #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 (#862)

* Added TestThreadContext and exposed it in ContextManager and Steps base class (#875)

* Added TestThreadContext and exposed it in ContextManager and Steps base class

* Upgrade to BoDi v1.3 (#876)

* fix shadow copy test issue
* upgrade BoDi to v1.3
* remove unnecessary BoDi workarounds

* Adds support for xUnit2 ITestOutputHelper #575 (#874)

* Resolves #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 (#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. (#906)

use FileStream constructor which grants ReadWrite to other processes

techtalk#904

* Added changelog entry for PR (#907)

* correct version number

* Access MSTest's TestContext property via ScenarioContext (#882)

* injected MSTest's TestContext into ScenarioContext

* fixed TestContext property generation for VB.Net

* @MSBuild [DeploymentItem] - added option to provide output directory (#901)

* @MSBuild [DeploymentItem] - added option to provide output directory

* code review

* update changelog after merging PRs #882 & #901

* add tests for Feature/Scenario Hooks with context parameters (#925)

* Issue Template (#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 (#942)

* Avoid trying to load empty configuration

* Set ConfigSource of default holder to "Default" instead of "AppConfig"

* Turn off line ending git auto conversion (#953)

* Stop git from automatically converting line endings everytime repo is cloned
* add .vs folder to .gitignore

* Fixing copy link in step definition report (#958)

* Update changelog

* Support for tuples (#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 (#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 (#965)

Remove ambiguity regarding where to go for questions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment