I've recently been trying to implement automated unit test within my Jenkins pipeline using the nunit3-console.exe, for multiple Test projects that implement Microsoft and Asp.Net related functionnalities within their set-up methods.
The test projects are in Net 5.0 and trying to run them will give me this error:
1) SetUp Error : MyProjectPath
System.IO.FileNotFoundException : Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The specified file could not be found.
at MyProjectTest.StartTest()
This is obviously not the only missing assembly, as it requires many of the Microsoft.Extensions and Asp.Net related dll to functions. Manually supplying said DLLs to the Test folder directory does allow the command to properly run, but this is obviously not a great solution in the long run. Supplying the missing assemblies to the GAC would also fix the problem, but only as long as we don't update any of our packages.
What would be the intended workflow when a Test requires such DLLs? Where should they be placed so that they can easily be maintained and/or replaced after updates? I've tried using the .Net Core console runner hoping it might include these DLLs as well.
Thanks a lot for your help!
https://github.com/nunit/nunit-console/releases
Use the NUnit.ConsoleRunner.NetCore.
Related
Here's the relevant part of my C# library csproj file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net46;net48</TargetFrameworks>
<Platforms>AnyCPU;x64</Platforms>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
As the question states, my Azure CI build pipeline completes successfully, but I'm noticing that the Test task in my pipeline takes only 1 second - and that is due to the discovery of any 'test' .dll's is failing to find anything.
I am quite certain that it's due to my outdated test DLL discovery paths
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
The above is what USED to work, when there was only 1 target framework moniker.
Now that I'm trying to support multiple frameworks, I am wondering if there's a slick way to indicate that by tweaking these discovery paths (some type of wildcard technique that I can use everywhere, across different Azure DevOps projects)
I finally discovered that there is no magic discovery path that really works
My old pipeline was using Visual Studio Test task from the days when it was a traditional .NET Framework application
When I changed my .csproj to conform to the new SDK format (even though I was still building .NET Framework apps) I should have changed to a different type of task for doing the tests...
Changing to dotnet test did the trick. It has a different approach. Instead of wanting paths to compiled DLLs, it starts by wanting a pattern to help it find the PROJECT file
I am trying to get TeamCity set up for a project. I want to run a scheduled build that includes a step where NUnit Tests are run.
My NUnit build step looks like this:
Runtime: NUnit-2.6.3 v4.0 MSIL
Run tests on: **/Tests/*.dll
Execute: If all previous steps finished successfully
But every time I run the build I get an error saying:
No assemblies were found.
Why is this happening and how can I fix it? Also, conceptually, this build step will happen BEFORE the project is actually built. But how will there be any Test DLLs (assemblies) unless the project is built in the first place?
I would suggest that you build your projects before running tests. Most common way to achieve this is that you have separate configurations for building code and running tests.
Your build configuration would generate artefacts (containing assemblies most likely).
Test run configuration would extract this artefact package, via artefacts dependency, then in build step you run tests from specific assembly.
This is the most common approach and using this approach you do not have to worry about files in the files system. Teamcity's snapshot isolation and artefacts dependencies will take care of this (when properly configured)
If you need an example how to achieve this, let me know.
We had a unit test project (exe, using NUnitLite) that referenced the main application to unit test code within the main application (an exe).
This used to work, but now Xamarin is giving an error that we can't reference an exe project.
Why is this?
What alternatives do people suggest for unit testing application code? It seems wrong to have to move all application code from the exe to an assembly just for the purposes of unit testing.
It looks like the feature was accidentally removed :-( Someone must have overlooked that valid, if uncommon, scenario. Please file a bug report on Xamarin.Studio and request this feature to be *re*enabled.
Until then I see two workarounds:
Build/execute the tests from a script (e.g. a Makefile). You can automate this to require less steps than using the IDE;
Add a pre-build step to your project to make a copy of the .exe and name it .dll. Then reference this copy of the assembly.
We are using VS2012 and TFS2012 and write unit tests for our code. We want to report code coverage, and also using .config files in our unit tests for test appsettings, and also some other settings for logging, MS Enterprise library settings etc. etc.
App.config not working in new test framework
New test framework of MS should be great, but to me it is not so great at all.
How I'm i suppose to set some basic configuration in config files, when the new framework does not use config files anymore?
We had a problem with mixed mode dlls, and found a fix: adding
<startup useLegacyV2RuntimeActivationPolicy="true">
to the app.config. But this did not work for our unit test project. Becuase config files are not there anymore. Searching the internet came up with a solution
'Problems with .Net 2.0 Mixed Mode Assemblies inside Visual Studio .Net 4.5 Test Projects'
This means editing a file of Visual Studio 11 itself in the program files directory, not a great solution i think....
And how about some basic appsetting? How am I supposed to set this?
Do not use the .testSettings file
Using the old .testsettings file is also not recommended by MS, becuase then the old test framework is used. And if I use the .testsettings file, i cannot setup Code Coverage on my tfs2012 build service.
Another issue is that we have code that need a dll (system.data.sqlite.dll), but only at runtime the unit test code needs this dll. So a reference is not needed. We fixed this by using the Deployment tab on the testsettings file. But in the new framework, you should not use the testsettings file. You have the [deploymentitem] attribute if you need files. But the deploymentitem attribute can only be used on a [testmethod] not on a [testinitialize] or [assemblyinitialize] method. But our code needs the dll in the [testinitialize] method. So there is no way to get the dll in place.
Just copy it with File.Copy in the [assemblyinitialize] (or testinitialize) method does not work.
Adding the dll as file to the project, and set the 'copy to output directory' to 'Copy Always' as mentioned in 'Configuring Unit Tests by using a .runsettings File' also does not work at all.
The (really not great) solution for this is to add the dll as a reference, then instantiate a class and do nothting with it. This way the dll is needed otherwise it is not building, and thus the dll will deploy itself to the right directories.
how to solve my problem(s)???
- I want to use config files in my unit test.
- I want to deploy some files that are neede in the 'assemblyinitialise' and/or 'classinitialize' methods.
- I want Code Coverage on my TFS2012 nightly build enabled.
a) App.config not working in new test framework
This should still work. What I think is missing in this case is that this .config file is not being copied with your test dll. Could you please set this as a deployment item and try again?
b) Do not use the .testSettings file
.testsettings and code coverage.
Setting up code coverage with the .testsettings file IS still supported in VS 2012 build. You simply need to select the mstest 2010 test runner and specify your .testsettings file in your build definition
If you dont have anything except code coverage settings in the .testsettings file then you can easily migrate to the 2012 test runner and select "enable code coverage" in the drop down items
copying a file required by test initalize
You could do this via the .testsettings file or you can have a post-build file copy task. It is pretty straight forward to do so and has no impact on anything else. Using the "copy to output directory = copy always" does work. Please try it with a sample solution and see if you can narrow down on why this does not work on your setup.
I have some projects developed with C++ builder XE.
I would like to add some unit test, but the DUnit framework installed is nice for Delphi, but the integration with C++ builder is not so good (and very limited).
What other xUnit framework can I easily work with ?
In your case I'd start by asking Embarcadero for assistance. They want to fully support the developers who use their stuff, and automated unit testing is really critical to keeping them happy.
Until then, CppUnit works on any C++ code, but does not really integrate all that well with IDEs. The approach we've used is to create a new project to contain the tests, and have its linker include the path to the existing production project's .OBJ files. We set up a a project dependency so the test project depends on the production project.
In the Test project, we'll use different main.cpp files, one each for Debug and Release, and use conditionals to include/exclude the appropriate one from the Debug and Release builds.
For some "fake" integration, at least as far as running the tests go, in the DebugMain.cpp we'll load up the MFC TestRunner GUI, so the developer can click to select the tests they want to execute. In the ReleaseMain.cpp, we'll use the command line test runner, using the CompilerOutputter object which will let the build process know of success or failure. The output is also compatible with IDEs that interpret stuff like that, so you can click on a failed test report in the Output window, and the IDE takes you to the failing test assertion.