This is somewhat of a general question but I haven't found much by googling it. I have a test framework that sets up an environment for testing purposes. My application consumes this framework through a reference path and runs manual tests just fine. However, once I ask the build server to run my test the framework complains it cannot find any of my app settings. The app.config file sits in my testing project for my application and I am sure it exists in the correct bin folder on my build server. I'm doing this in a C# .NET environment.
EDIT:
I'm not sure what to be more specific about. I would imagine it's something with the build server since it seems to work running tests locally but I have no clue what to look at. Nothing else about the build server is failing, just getting the app settings.
The framework is .NET 4.0 while the main project is 4.5. I'm using nunit to run the tests and running them outside the build process but using the Nunit gui fails at the same point.
The code that grabs the app settings is pretty basic:
string databaseName = ConfigurationManager.AppSettings["databaseName"];
EDIT
Snippet of my test:
public class UserServiceTests : DeployDBEveryFixtureBase
{
public UserServiceTests()
{
DBSetup("Core");
DBSetup("Postal");
DBSetup("Common");
}
private UserService userService = new UserService(string.Format("Data Source={0};Initial Catalog={1};User ID={2};Password={3};",
ConfigurationManager.AppSettings["targetServer"],
ConfigurationManager.AppSettings["databaseName"],
ConfigurationManager.AppSettings["userID"],
ConfigurationManager.AppSettings["password"]));
[Test]
public void UserService_Get()
{
// Act
User user = userService.GetUser(Guid.Empty, "*****", string.Empty);
// Assert
Assert.IsTrue(user.FirstName == "System");
}
}
The environment deployment is in the base class of DeployDBEveryFixtureBase. The DBSetup calls ensure that each database is deployed in the proper order. All of those seem to run fine and my tests complete but I still get the described error. If I look at the database I can all the datbases being properly deployed and then removed (the base class includes a TestFixtureTearDown) but it seems like the build process is trying to run it again.
Note: I am only building the solution file during this process. I do not currently have a .proj file in the build.
Without knowing much about your build server or how exactly you run your tests there is only one issue which comes to mind, that is Shadow Copying. Can you check if your unit tested DLLs are not shadow copied to some location where the app.config file doesn't exist?
Apparently my testing framework had an empty constructor that wasn't so empty. It looks like the app.config was being properly queried but was returning an empty result set since the empty constructor did not have the proper arguments. After removing the contents of the empty constructor my test ran fine. Thank you all for the help.
Related
Working with specflow latest version, When I run my scripts I get result set cannot be started and been at this for a week. the automation script run to completion but it bring up this error and test fails .The specflow version 3.1.97 is and visual studio is 2019 . I have narrowed it down to a simple test and still fails , it seems to have something to do with specflow. I do not want to have to create a new solution and start again and I have wrote a lot of tests but cannot go any further as reports will always fail due to this error. I have checked online . I have tried different solution including https://github.com/SpecFlowOSS/SpecFlow/issues/1851 etc but to no avail.I have gone down version of specflow, specfow.tools.MsBuild.Generation ,nunit but still the same. If I create a new solution and add these dependencies it seems to be fine and do a quick test is works fine.
Feature file:
#Settings About
Scenario: About Screen
Given user is already logged in
Step definition:
[Given(#"user is already logged in")]
public void GivenUserIsAlreadyLoggedIn()
{
Assert.IsTrue(true);
}
I received this error message after moving my feature file into a shared assembly. The reason for the error was that the static initialization methods generated by SpecFlow.MSBuild was not being called at startup. I fixed by chaining the call from the corresponding initialization method in the top level test assembly.
Although the reason for your problem is probably different, I suspect you can diagnose the problem using the same process.
In the obj folder of your test project there should be a file called MsTest.AssemblyHooks.cs. Move this file into the main project folder and include in the project.
Add the following xml into the csproj project file. (This turns off automatic hooks file generation).
<PropertyGroup>
<GenerateSpecFlowAssemblyHooksFile>false</GenerateSpecFlowAssemblyHooksFile>
</PropertyGroup>
You can then put a break point on the initialization code and debug. (You may be getting exceptions, or the initialization may not be being called.)
Note - you may be able to debug the initialization code in place without moving. In my case I needed to modify the code, hence a permanent non-generated version.
For anyone else trying to split the feature file into a shared project, you also need to update app.config with
<configSections>
<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow">
<configSections>
<specFlow>
<stepAssemblies>
<stepAssembly assembly="[TODO - SharedAssemblyName]" />
<stepAssemblies>
</specFlow>
I had the same problem. However after a pure uninstall all Specflow related packages, then reinstall everything, it works fine? Go figure~ I'm testing 3.1.97 now. Once stable I'll try to 3.3.
Get rid of everything in your solution that uses or requires Specflow, then reinstall each package from scratch.
I have a C# class with the following code.
class Database
{
private const string DatabaseFilepath = #"Settings\Database.xml";
...
private void LoadDatabase()
{
XmlDocument databaseDocument = new XmlDocument();
databaseDocument.Load(DatabaseFilepath);
}
}
Now this code executes fine when I compile it, and it is able to read from the Database.xml file. However, when I run a unit test that happens to execute this code using NUnit, I get the following exception.
Result Message: System.IO.DirectoryNotFoundException : Could not find
a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Settings\Database.xml'.
Now, when I was using Visual Studio Test Tools, this worked perfectly fine. However, upon switching to NUnit, it looks like it is searching in a different working directory. How can I change this?
Note: I have found other questions that ask how to use relative paths in test code. In my example, my relative paths are are in my class code.
Charlie gave a great explanation for why they decided not to change the current directory. For my code under test, I found using AppDomain.CurrentDomain.BaseDirectory and combining it with my relative path using Path.Combine(...) to work fine for NUnit 3.x.
As a matter of policy, we decided that NUnit 3 should no longer change the current directory when running tests as it did in V2. With V2, you could run a whole list of assemblies in different locations and NUnit would change the cd to the location of each assembly before running it. We stopped because:
Changing the current directory is an unfriendly thing for a program that runs other programs to do.
It won't work anyway, since multiple assemblies located in different directories could be running in parallel at the same time.
There's an easy solution for test code, but you say this is code in your application under test so the solution is a bit different.
In the short term, your tests can set the CD before running the SUT code that requires it to be set a certain way. I recommend doing this in some level of SetUp and restoring it in the corresponding teardown.
In the longer term, fix your SUT so that it doesn't require the CD to be set in a particular way in order to run properly.
We are developing and maintaining a legacy winforms application. The application uses a domain model which ist quite separate from the GUI layer, but because of many dependecies, it is hard to unit test. At least we have a build and an installation script which we can use to automatically build and deploy the application.
Now if we could only have some automated system tests...
We came up with the following idea:
First, we could write our tests in script files like this:
public class Test
{
public void TestSaveACustomer()
{
var c = new Customer();
c.Name="Miller";
Mapper.Save(c);
Assert.IsTrue(c.CustomerId >0);
}
}
Then, after building and deploying the application, we could run the scripts with a script runner that is baked into our application binary. We imagine we could use the following commandline
myapp.exe /runTest c:\myScript.cs
We could start to build our own Testing framework, wouldn't that be cool? ... er... no. It would be much less work if we could use an existing testing framework like nUnit, xUnit or MSTest from our application .
I guess I need to
Start a UnitTestRunner
Compile the Script
tell the runner to run the tests in the compiled script assembly.
I have no idea where to start, because I have only used UnitTests from VisualStudio.
Would that be possible with any existing testing framework? Which are the main classes I would use?
Here a existing answer how to run NUnit tests by yourself.
Question is, what does you prevent from running the tests regularly?
To get to run myApp.exe c:\test\test.cs you would also need to compile the test, then run it. You still need to compile it against your app?
Can you debug your application from let's say Visual Studio? Right? So, you could add a 'sub project', which points to the main project for the dependencies and your code. Then you add your tests there, using NUnit regularly.
Or what does prevent that?
I have a hudson server running on my local machine. So far I have only added one project to hudson. I am using svn as my source control. Whenever I build my project on hudson, all the test fail because the %PathToWebApp% variable cannot be recognized by hudson. I can force hudson to recognize the PathToWebApp if I add it as an environment variable in hudson, but then that only works for one project. I need hudson to work for multiple projects. Btw, I can not use absolute paths for AspNetDevelopmentServerHost any given project will be running on multiple machines. The sample asp.net code is listed below. Its a very basic asp.net test method.
[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("%PathToWebApp%\\MyReportingApp", "/MyReportingApp")]
[UrlToTest("http://localhost:51357/")]
public void LoginConstructorTest()
{
//Login target = new Login();
//Assert.Inconclusive("TODO: Implement code to verify target");
}
Ok I figured it out. Hudson does not recognize the attributes. The settings for the test has to be configured in the Local.testsettings
When I try to run Unit Tests (mstest) I run into this issue.
The line of code:
_mainCnStr = System.Configuration.ConfigurationManager.
ConnectionStrings["main"].ConnectionString;
Comes back as a null reference
It doesn't do this in the main UI project when I run it. What is the right method to get this connection string setting seen by the Unit Test project? I tried embedded as a resource. I tried Copy Always. What is the right combination of settings that will fix this for me?
One thing to watch with MSTest (from the IDE at least); it doesn't run the tests in the regular output (bin) folder, and it doesn't respect the project's file inclusions ("Copy to Output Directory"). You often need to explicitly tell it (MSTest) which files to put into the test area. You will need to include the "app.config" in this list; either via the testrunconfig ("Deployment"), or by adding an attribute ([DeploymentItem]) to the affected test fixtures.
You should add an app.config to the unit test project. It won't automatically use the settings in UI application's app.config.
I'm assuming mstests are, like nunit tests, embedded in a seperate assembly which gets loaded by the testing application? In that case, you may need to create some test set-up code which loads in the configuration file.