How do I get my App.config file to be recognized/used by the NUnit GUI runner? I have tried placing it in the top folder of my project and in the same folder as my feature files. Here are the contents of my App.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<runtime detectAmbiguousMatches="true"
stopAtFirstError="false"
missingOrPendingStepsOutcome="Error" />
</specFlow>
</configuration>
Specifically I am trying to tell NUnit to have a fail result when there is a missing or pending step which is why I am specifying "Error" for this. This actually works correctly when I use TestDriven.net but not when I use the NUnit GUI runner. The GUI always shows a green bar and displays the test as Inconclusive instead of Error or Failed.
I am launching the GUI with this command line argument:
E:\Program Files\NUnit 2.5.5\bin\net-2.0\nunit.exe "E:\ACSreader new work\ACSreader2 Working Copy\trunk\ACSreader2\ACSreader2.sln" /config:Test
Update concerning NUnit GUI Runner:
NUnit-Runner seems not to properly display/report inconclusive tests. An inconclusive test is displayed green in NUnit-GUI, while TestDriven and ReSharper display it yellow.
As shown in the question, SpecFlow can be configured to report missing steps as Errors and not as Inconclusive.
The configuration happens in the App.config of the project that contains the feature-files. The usual mechanism for App.config in .NET is applied. That means at runtime the config info has to be in a file called .dll.config. The runtime provides then the config to SpecFlow. SpecFlow does not read the config itself from App.config!
Make sure that at runtime the correctly named config file is present alongside the dll that contains the test fixtures. VisualStudio usually does that transparently when building a project.
Original answer:
The App.config has to be in the root folder of the project that is containing the test-fixtures (the project that contains the feature files).
Have a look at the examples on github. There are several App.config files in different projects:
http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests/
http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/
http://github.com/techtalk/SpecFlow-Examples/tree/master/BowlingKata/BowlingKata-MsTest/Bowling.SpecFlow/
See my answer nunit and configs
You need to tell nunit what the name of the config file is. it looks for namespace.config by default it seams
Related
I have been running my tests with Specflow+ through Test Explorer in Visual Studio and a nice .html report is automatically generated at the end by the Specflow+ Runner.
I have switched to Nunit Test Runner (still running through Test Explorer).
However, at the end I can't see any results files at all xml or html?
How do I get it to generate these? Or am I looking in the wrong place?
I tried adding a .runsettings file in the root of the project containing the following code but still no results were written:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<NUnit>
<TestOutputXml>TestResults</TestOutputXml>
</NUnit>
</RunSettings>
It's necessary to tell TestExplorer to use the .runSettings file. See https://learn.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019
I have a project containing azure function implementations. My project .csproj file looks like below.
I haved added a test project for the same and implemented unit tests using Xunit. My test project .csproj looks like below.
I have added a Visual Studio Test task in my build definition with below configurations.
How can I include only project and test project for calculating code coverage?
You can use Run settings file which is the configuration file used by unit testing tools. Advanced code coverage settings are specified in a .runsettings file.
You can exclude specified assemblies from code coverage analysis. For example:
<ModulePaths>
<Exclude>
<ModulePath>Fabrikam.Math.UnitTest.dll</ModulePath>
<!-- Add more ModulePath nodes here. -->
</Exclude>
</ModulePaths>
Then add the .runsettings file in source control, specify the file under Setting file area in Visual Studio Test task
Please see Customize code coverage analysis for details.
I am trying to build a NuGet package that includes native DLLs which are to be placed in the output folder when a project uses the package. I have tried to use the several suggestions from this question, but I am always running in the same problem.
My current NuGet package layout is like this:
\build
packageId.targets
file1.dll
file2.dll
\lib
\netstandard1.4
assembly.dll
The contents of packageId.targets is:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<NativeLibs Include="$(MSBuildThisFileDirectory)\*.dll"/>
<None Include="#(NativeLibs)" Link="$(RecursiveDir)$(Filename)$(Extension)">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
This should, according to the answers of the other questions, lead to my DLLs being placed in the bin\Debug directory of the project using the package. However, they are not. Instead, they are placed in bin\Debug\packages\packageId\build.
Now I have experimented a lot, and I noticed more and more strange behavior which I cannot make any sense of:
If I move the DLLs to the root of the NuGet package (like one answer suggests) and change the .targets file accordingly, they are not copied at all. There also is no error message.
If I change the .targets file to only reference file1.dll in both Include= and Link=, both files get copied anyway.
So I wondered if some policy just ignores the .targets file and copies whatever is in build to that path in the output folder, but when I remove the .targets file, the DLL files will not get copied anymore.
Now I understand even less what's happening.
What do I need to change to get the DLLs copied right into bin\Debug?
The new way to handle runtime-specific assents in NuGet is to use the runtimes folder to place native assets:
\lib
\netstandard2.0
ManagedWrapper.dll
\runtimes
\win-x86
\native
NativeThing.dll
\win-x64
\native
NativeThing.dll
\linux-x64
\native
libNativeThing.so
\osx-x64
\native
libNativeThing.dylib
If the package is consumed from a .NET Framework project, you may need to add a reference to the Microsoft.NETCore.Platforms package wich provides the runtime graph (runtimes.json) for NuGet to provide proper RID mappings if you don't use base RIDs (e.g. win10-x64 falls back to win-x64 resources).
I have various projects in a Solution with many tests, one of them use entities and has the following behaviour:
If I right click run all tests on my project everything runs smoothly but if I right click on my solution and does the same I get:
System.InvalidOperationException : No connection string named 'Entities' could be found in the application config file.
I have of course those lines in my App.config
<connectionStrings>
<add name="Entities" connectionString="metadata=res://*/Sales.csdl|res://*/Sales.ssdl|res://*/Sales.msl;provider=System.Data.SqlClient;provider connection string='data source=(LocalDB)\v11.0;attachdbfilename="C:\Users\louis gentil\Documents\Visual Studio 2013\Projects\TFS\LouisGentil\SQL\ModuleSQL-Database.mdf";integrated security=True;MultipleActiveResultSets=True;App=EntityFramework'" providerName="System.Data.EntityClient" />
</connectionStrings>
<entityFramework>
More info asked by kif:
It is in Visual Studio
I use resharper as a unit tester
I don't know if test project compile into an app, I don't thnk so it is just a class library I use for test.
It has it's own app.config indeed.
The above error is when I right click on my solution and ask resharper to run the unit test nomatter what project is the startup project.
Do you have any idea about what could cause this behaviour?
Try selecting "Use separate AppDomain for each assembly with tests" in ReSharper → Options → Unit Testing. This is an optimisation ReSharper makes that reuses AppDomains (they're expensive to set up), but has the side effect that only one app.config can be loaded, and it might be the wrong one.
I have a .NET 2008 solution with a project that acts as WCF Service host. That project has a web.config file with settings that will be replaced by the installer when the project is complete. Those setting are components that make up the connection string and a few others.
This WCF project references a Business Logic project(class library which implements service code) which in turn references a DAL project which uses the Entity Framework.
What I would like to know is how can I get the values in the web.config in the WCF project to the DAL? Without using any relative paths that I have seen with OpenMappedExeConfiguration. I need to build up the connection string in the DAL based on the setting in the web.config file.
Thanks for your answers.
I`m storing shared things like connection strings in 1 folder, which even is not under folder where source code lives. In DAL tier i just use ConfigurationManager to pick it up.
In project, which starts application (in your case, it`s WCF project), i add "ConnectionStrings.config" file from my external "config" folder AS A LINK (in visual studio, press 'add an existing item' -> choose item -> next to "Add" button is an arrow where this option lives). Then i just set it through that file properties (click on file in solution explorer -> press F4) as a content of project and that it should be copied once again if modified to deploy folder. Then i add a new app.config file to project, which includes "ConnectionString.config".
Source of connectionstrings.config:
<connectionStrings>
<add name="MyConnectionString"
connectionString="Data source=tralala"/>
</connectionStrings>
Source of app.config in WCF project:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
</configuration>
I'm not sure that this is the best approach. But so far so good.
Unfortunately, the answer to your question is "copy and paste". This has always been true.
The closest thing to an exception to this rule is the "new" .NET 2.0 Settings files. Because the structure and default values for these are part of the assembly defining the component, the component can, upon startup, cause the default values to be written to the applications configuration. I imagine one could couple that with a piece of code to work with installutil to cause the defaults to be written out before the containing application is ever started, leaving the defaults in the config file to be edited before the application is used for the first time.