I'm having a strange problem. I have a bunch of integration tests projects. Each test project has a configuration file (app.config).
Currently, in my "Run Integration Tests" build step, the NUnit3 console runner allows me to specify only one config file (where it says "Path to application configuration file"). I have specified the path to one of my integration test app.configs. The problem is, the tests in other test projects fail because the Nunit3 console doesn't recognize their app.config files.
How can I have TeamCity run each test project with its own app.config file in its bin/release folder?
FYI: This is what I have specified in the NUnit assembly lookup: **\bin\Release\*.Integration.Tests.dll
Turns out, this was my problem. After removing all references between my test projects, I noticed that the build time was reduced by 50%.
Related
Just trying TeamCity for our applications, however, when we try to build the project it fails as the projects are built out of order, causing a crash and it failing to continue.
I have manually run MSBuild against the solution file and it runs correctly. Is there any extra configuration we could have missed when setting up the server?
Windows 10
Visual Studio 2017
TeamCity 2017.1.2
GitHub
I'm working with a VS solution that locally behaves as expected. Main-project has some package dependencies. Test-project has project-ref to main project. VS local compile succeeds. Main-project refs + dependencies are copied to MyProject/bin/debug; test-project refs + dependencies are copied to MyProject.Tests/bin/debug; ReSharper local run of tests succeeds.
However my TC project has problems running tests.
My build-config steps are : pull from GitHub , run Visual Studio (sln) build , trigger NUnit.ConsoleRunner to run tests vs built assembly - which throws a file not found error (can't find package dependency assembly ) that perhaps indicate the build steps needs to save as artifact the dependent assembly and copy it to the test output dir.
However looking at the agent work dir I find the dependency assembly present in both the main-project and the test-project :
C:\TeamCity\buildAgent\work\64f706c42d79250c\{main-project}\bin\Debug\{dependency}.dll
and
C:\TeamCity\buildAgent\work\64f706c42d79250c\{tests-project}\bin\Debug\{dependency}.dll
which indicates that VS build step copied {dependency}.dll into bin as expected.
So why can't NUnit find it ?
[19:27:48][Step 5/5] MyProject.dll
[19:27:48][MyProject.dll] MyProject.UnitTests.MyTest
[19:27:49][MyProject.UnitTests.MyTest] System.IO.FileNotFoundException : Could not load file or assembly 'MyProjectDependency, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
[19:27:49]
[MyProject.UnitTests.MyTest] at ReferencingCode()
at MyProject.MyClass.Answer() in C:\TeamCity\buildAgent\work\64f706c42d79250c\MyProject\MyClass.cs:line 9
at MyProject.UnitTests.MyTest() in C:\TeamCity\buildAgent\work\64f706c42d79250c\MyProject\UnitTests.cs:line 10
[19:27:51][Step 5/5] Failed tests detected
I'm wondering if the output dirs are different for the VS Build and NUnit steps ? But my agent work dir is identical to my local VS solution dir - so where would TC be locating the NUnit work dir ?
It looks as if you have two completely separate output directories, one under the test project and one under the main project. Your tests, of course, are run in the directory that contains the test assembly.
The output messages seem to say that the main assembly is being copied into the test assembly directory - the reference from the test project must call for a local copy. We can tell that because the test assembly and the main assembly both have entries in your stack trace. The dependent assembly, however, is probably not referenced by your tests, and so does not get copied. At least that's how I read it - verify by looking at the directory contents.
You could solve this by using the same output directory for everything, but that would probably involve changing the directory structure you are using. A simple fix is to add a reference to the dependent assembly to your test project and set local copy true.
For your tests to run, locally or in TeamCity, your test project must have a project reference to the project you are testing. It does not work any other way. How else would it know what to test? So check your references in the test project, and make sure the output is the same place when the build runs as "Debug" and "Release".
On a side note, letting TC do the actual build and test is fine for simple stuff but it's very hard to troubleshoot. I recommend you build a PowerShell script with PSake and create a "Test" task. That way you can run the script locally and TeamCity can use the same script you are running locally.
When I try to execute NUnit test in VSTS task I am getting the following error:
Warning: The path 'C:\a\1\s\INCASOL.IP\packages' specified in the 'TestAdapterPath' does not contain any test adapters, provide a valid path and try again.
I have these tasks in VSTS:
The "Run unit test" task is configured as follows:
Note I have set the "Path to Custom Test Adapters".
I think the dlls for NUnit are properly copied to packages folder because in "Nuget restore" task I can see the following:
Added package 'NUnit.2.6.4' to folder 'C:\a\1\s\INCASOL.IP\packages'
Notes: The NUnit version is 2.6.4 and I'm using Hosted Agent
After a few hours looking for a solution, I solved it few minutes after having asked my question.
Although I could run my test in my local machine using NUnit Test Adapter, this package hadn't been added to my packages folder. So, once I run
Install-Package NUnitTestAdapter
for my test projects, everything works fine.
On the TeamCity server we have installed VS 2012.
I have created a build configuration in TeamCity that builds and deploys the solution.
I have added a MSTest 2012 Configuration as well, but don't know how to tell it what project is the VS 2012 test project so that it can run those tests.
Thanks
You need to specify assembly file (dll) of your tests, not the project file (csproj).
Here's an example: http://shrani.si/f/p/PH/2tO4Zo5s/tmpa4cc.jpg
So let's say your Testing assembly is called Company.Tests.dll and it is located in Company.Tests/bin/Debug/Company.Tests.dll
Basically, in "List assembly files:" you must put the path (You can use wildcards)
For example:
**\bin\**\*.Tests.dll
This will locate all assemblies with .Tests.dll suffix.
Regards
We have a TFS build definition set up where we pass the following extra MSBuild arguments in:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\server\build";AutoParameterizationWebConfigConnectionStrings=false
This has been detailed elsewhere as a way to have the published files copied to a specific location instead of generating a deploy package.
This unfortunately does not work on our build server, however if I run the exact same msbuild command line as called by TFS on my dev machine then it works perfectly and copies the output files to the location.
I have checked the log file and there is no errors, it just seems to completely skip the publish/deploy step.
Done building target "_BuiltWebOutputGroupOutput" in project "xyz.csproj".
Target "PrepareForRun" in file "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets" from project "C:\Builds\2\xyz\xyz build\Sources\xyz.Web\xyz.Web.csproj" (target "CoreBuild" depends on it):
whereas on my local machine, after _BuiltWebOutputGroupOutput target is run the package target runs and deploys the files correctly.
I have tried using different paths and even setting the properties in the project file but it seems to make no difference. My local solution and project files are the same as in the repository that the TFS build is using. Is there something config related on our build server or with the build agent that would cause the packaging target not to run?
I was having a similar problem today and found a fix so it maybe worth a look for you. Here