I've got a class that I want to test with xUnit. This class loads a .json file containing configuration for this class in the constructor. By default, this json file is loaded from the current directory. This works fine in my application, as it can resolve the current working directory. This json file has the Build Action = Content and Copy to output directory = Copy Always to ensure the file is always along side the DLL files.
However, when calling the tests from within the VisualStudio test runner, the DLL's are run from the tempory files location: C:\Users\<username>\AppData\Local\Temp\3c081508-0a25-45f0-8813-48d4fcabccaa\3c081508-0a25-45f0-8813-48d4fcabccaa\assembly\dl3\4175808c\f164e239_d1a1d201\SomeLibrary.dll where each DDL required is in a separate file, and the .json file is nowhere to be seen. This means the code that loads the .json file from the current ddl location is failing. The functionality happens when running the tests from both within VisualStudio, or from within the xUnit.console application.
To overcome this, I've added a configuration option, and if that configuration option exists (which I add to my test project only), then use that path instead of trying to load the path from the current ddl. However this is now failing in bamboo, as that path is invalid when executed on the build server.
Is there anyway to get the temporary path programatically to where the .json file is... Or someway to disable using these temporary files and just use the actual bin dir in the project build dir for the VisualStudio test runner?
Currently using VisualStudio 2017 and xUnit 2.2.0.
Cheers,
Justin
There is this option for xunit tests called Shadow-copy assemblies being tested. It ensures that the assemblies being tested are copied elsewhere to allow the original assemblies to be modified while running and without affecting the tests.
Turning off this feature should help in your case.
Shadow-copy assemblies being tested can be turned off in Visual Studio at
Resharper -> Options -> Tools -> Unit Testing -> Shadow-copy assemblies being tested.
Related
I have a U-SQL DB Project (USQLdb) that defines a U-SQL database and it's constituent tables, procedues, etc. This project also references two assemblies for use in one of the stored procedures. The DLL files are held within a folder called assemblies within the U-SQL Data Root folder and are referenced within the database using the following script:
CREATE ASSEMBLY IF NOT EXISTS [Microsoft.Analytics.Samples.Formats]
FROM "/assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll";
This works when deploying to Local-machine or to Azure.
For testing purposes, I have added a U-SQL Application Project (USQLScripts) that references USQLdb, with U-SQL scripts that execute a stored procedure each with the aim of setting up Unit Testing.
When trying to run these scripts against Local-project: USQLdb however, database deployment fails. From the logs it is because the USQLdb deployment script cannot find the referenced assemblies in the Local-project data root folder:
*** Error : (204,6) 'Assembly file 'C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot\assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll' could not be read.'
I have specified the USQLScripts Test Data Source as the local U-SQL Data Root folder which copies all files found to the Local-project working directory here:
C:\<Solution Folder>\USQLScripts\bin\Debug\USQLScripts_altdata_5qktnwfj.gln\data'
though per the error message above, the USQLdb Assembly Reference is trying to find them here:
C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot
As the DataRoot folder is completely cleaned and recreated on each Local-project execution, how can I either get the assemblies into the DataRoot folder on execution or reference them approriately without changing the address in the U-SQL script included earlier, which works as required when deployed to Azure?
Turns out, that if I remove the U-SQL Database reference in USQLScripts, the files that are in the Test Data Source folder are now copied to the C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot folder, but the scripts cannot execute as the database they are trying to execute against hasn't been referenced. I get the impression that I am either missing something or have hit a bug/unintended behaviour...
Turns out I was missing something.
What I thought was an error in referencing the assemblies was actually an error in building the USQLdb project, that resulted in the assemblies not being available and a red herring of an error being thrown.
The culprit was the Target Framework Version of the assemblies being higher than both the USQLdb and USQLScripts projects. It appears this can only be changed by editing the .usqldbproj files manually in a text editor (specifically the <TargetFrameworkVersion> value), as there is no option within the Visual Studio UI to edit this project property that I can find.
Once I upped the Target Framework Version in the U-SQL projects to match those of the assemblies, everything now builds, deploys and executes as expected.
I am currently working on a small program which prepares the environment for testing (reverts the snapshot of a VM, upgrades our software to latest version, etc) and then launches some automated tests via MSTest.
The tested software creates some files which I copy to my \out folder (defined in Default.testsettings) so that after execution my test launcher can copy them to their final destination. That final destination is not known from my test implementation, thus why I first copy them in my \out folder temporarily.
Unfortunately, the issue I am having is that the contents of that folder is getting deleted at the end of each test. A workaround would be to just use another location for the temp folder, but then I'd have to add a field in an xml configuration file to specify that location, whereas the \out folder is implicitly known by both my test launcher and tests implementation.
What is the reason that this folder/folder's content are getting deleted at the end of my test execution? What can I do to keep them?
Thanks
EDIT: If it makes any difference, I am running the test one by one for now from within VS itself, and not running it in a "deployment" environment with my test launcher that calls mstest, etc.
My program deals with input and output files and therefore need to have an access to a folder (included in Visual Studio Project) with existing files, and also create new files and check what's inside.
Tests run on several machines, so absolute path is not an option. Also, I can not self-generate input files.
How I can tell in an NUnit test that I need a folder which is located inside project source tree? NUnit seems to place exe code in some obscure temp folder.
Edit: NUnit 3 is used
Presuming this question refers to NUnit 3, sounds like you need to use TestContext.CurrentContext.TestDirectory.
This gets the directory the assembly was built to, rather that the temp location where it is ran. (Which Environment.CurrentDirectory would return.) Documented here. I believe CurrentContext can also sometimes be null, we use TestContext.CurrentContext?.TestDirectory.
For NUnit 2.X - I believe tests run where they are build, so Environement.CurrentDirectory should be sufficient.
I have a content file (xml, build action = content, copy always) in a class library (dll).
Many times when the host application (unit test dll, or web app) get recompile due to changes, this content file is not deployed.
it only get to deploy if i explicitly perform a "rebuild" at the host application.
is there a setting a way to ensure the file always get redeploy? already set it to "copy always", but doesn't work as expected.
There are two ways to solve this:
1) If you change non-source code files visual studio doesn`t automatically rebuild - they aren't considered when the compiler check occurs.
You may force a complete rebuild by deleting your output directory.
2) In the file properties in Visual Studio, set:
Build action: None
Copy to output directory: Copy always
Sometimes this helps
Edit: Also consider marking the file as content
I'm currently using the default build process template in TFS 2013 for my automated builds.
I've configured the OutputLocation parameter to be AsConfigured to get the same folder structure as my Visual Studio solution (there are multiple projects in the solution and I don't want them all to be dropped in the same folder).
The problem is that when the build process tries to run the tests, it looks for any assembly under the bin folder, while my build configuration makes it so that there is only a src folder.
Is there a way to specify looking into the src folder instead? Shouldn't it be the default anyway when using the AsConfigured setting?
Edit: Just to make it clear, there are usually 3 folders generated when running a TFS automated build (src, bin, tst). When using AsConfigured for the output location, there is no bin folder. I tried a suggestion which required changing the Test sources spec setting of the build process, and I get the same problem as before:
There were no matches for the search pattern C:\Builds\8\MyProject\MyBuildDefinition\bin\***test*.dll
What I ended up doing is using a PowerShell script as a post-build event to copy my test assemblies to the bin folder of the build.
There are PowerShell scripts made available for TFS 2013 on CodePlex, and I modified this one slightly to accomodate my needs.
By doing this, I was able to use the default settings for running the tests, and it worked like a charm.
In your build definition, change the value of setting "Test Sources spec" to ***test*.dll (assuming your unit tests assemblies are suffixed with .test.dll)
EDIT: Please use **\*test*.dll;**\*test*.appx
Try to use this file masks: ..\**\*test*.dll
It works for me.
I have "AsConfigured" setting on for X64 platform that places the binaries into src\x64\Release\ (and it used to place them into bin\x64\Release\ without that switch). So, I ended up using ..\..\..\src\**\*test*.dll as my "Test Sources spec".