I'm very new to MSpec and BDD in general and are currently having trouble having mspec pass a Search class that looks up employee data via an XML feed. The parameters for the url are held in an app.config file and seems as if the app.config is not being accessed to obtain the config setting.
Otherwise mspec is running fine for all other tests so far its just this one particular.
How do I write a test to utilise or mimic if thats needed, for the config file access please ?
Thanks
You probably have app.config in your production code project (project which is being tested), try adding the same app.config in Tests (project with MSpecs).
Related
It's a question I see on here but solutions aren't working.
I have a Multi Project Solution set up like so
The sole purpose of the "Console" is to start/stop the "Controller", the "Controller" the handles the "Plugins".
"Console" is a Console Application the other projects are class libraries.
I've just added log4net to the "Controller" project to write logs to the database.
In DEBUG it works perfectly and logs to SQL.
However once built in release, published and deployed it is failing to log.
I've kept all the log4net config within the Controllers "app.config" and know this is being used because the "app.config" has some other settings present.
Attempted Solutions - ALL WORKING in DEBUG but not Published/Released Version
Changed SQL connection string to a USER & Password from Windows
Changed log4net to separate config file and setting build properties to CONTENT and COPY ALWAYS
Using the below code to configure log4net in either he "AssemblyInfo.vb or the "Contoller.vb" file
Assembly: log4net.Config.XmlConfigurator(ConfigFile:="app.config", Watch:=True)
Any potential ideas please?
NOTE:
If I remove the explicit ConfigFile:="app.config" LOGGING DOES NOT WORK
NOTE 2:
Setting an absolute file path on the server for the ConfigFile enabled the Published Installed version to work. Is this the best method?
I'd like to write one suite of SpecFlow tests that test my web application (using Selenium) in various environments.
so I have a test written like this
Given that I am on the login page
which in turn leads to a step definition that boils down to
driver.Navigate().GoToUrl("http://www.myapp.com/login.aspx");
However, I want my test to be able to run against "http://localhost" or `"http://test.myapp.com" as well, without having to recompile. The best idea I've come up with is to place these sorts of settings in the App.config file, but that has its problems as well.
Does anyone have suggestions on how best to achieve this? Basically I want to pass in environment settings for my tests at runtime.
You can do this by changing the config file through the build process using transforms and there are tools that will let you run the transform outwith the build process (so you don't have to manually change it and you avoid a build) using the command line. This has been talked about already on SO:
Web.Config transforms outside of Microsoft MSBuild?
For example using PowerShell.
I would still question whether you might be better and starting a local instance of the service that you wish to test, rather than connecting to something which is out of the tests explicit control. You could instead use a method similar to self hosting a web api or host a wcf service to do this for you. This way you can inject mocks, modify and reset the database, or perform any other action you want.
If that still isn't what you need, an alternative to config files would be to setup environment variables that can be read at run time, see How to pass Command line argument to specflow test scenario
In our WCF solution we have one ConsoleHost (console application not class library) project and one WasHost Project. We use the Consolehost hosting for Dev environment and WAS hosting for production.
Now there are a number of .config files that are included using "include uri=file://services.config" in the Castle section of ConsoleHost project. I don't want to make a copy of this services.config file in the WasHost Project.
Is there a way to include files from other projects without making local copies of them? Or happy to hear other better ways of doing this.
Thanks
Ravi
You could do this a couple of ways.
One is to simply add a link to the source file from both projects as described here.
Alternatively you could embed the config into one of the common assemblies (Build Action=Embedded Resource in the file properties) and then use Castle's ability to include embedded resources. E.g.
<include uri="assembly://AssemblyName/xxx.config"/>
I am using NHibernate in a DAL layer dll. Local config file(app.config) is being used for db connection. This DAL component can be used in 2 different exe's and a NUnit test harness. Business requirement from Client is to have config information reside in exe's app.config file.
Is there a way to configure NHibernate to look for an app.config file based on the exe that it is compiled with?
Then in the NUnit test harness, look for a default config file?
Thanks,
Marc
As Dan hinted, NHibernate's main config section can either be in a standalone hibernate.cfg.xml, OR it can be put in the application's config file. If you want NHibernate's core config to vary by the currently executing environment (different apps, or during testing), you can go the app.config route. If no hibernate.cfg.xml file is found, NHibernate is going to look in the currently executing app's app.config file.
Here is an example of putting the NHibernate config in an app.config file: http://www.martinwilley.com/net/code/nhibernate/appconfig.html
I using unit testing, to ensure that I can read connect string information from the ConnectStrings section of my app.config file. This works fine in the application proper, However when I attempt to generate a unit test for this under the Test Project, the dll.config file is being ignored, and the connectstring info from the machine.config file is being retrieved instead. How do I ensure that my tests read from the correct config file?
Your test project must have its own App.Config file.
You should add an app.config file to to your test project and populate it with the necessary values. You may ask "Why can't I use the existing app.config in my project?" The real answer is probably out there but personally I like it this way because it means my test project never points at my production environment.