I have DLL plug-in, which I'd like to test and launch on TeamCity: it contains .h and .cpp files
What is the right strategy to test this DLL:
Create a new Test Project in the same solution, configure 'include directory' to see sources and copy DLL project files to Test console project. In this case I have the same solution but in console mode, which I can test in normal way. But if my DLL project will change I need to synchronize source files.
Create export function in my DLL, like 'runTests()' which will produce XML file with results. TeamCity will process this? And how should it run this? And some stuff function appears in release DLL...
To unit test our libraries, we create standalone unit testing console executables. so:
For each library , we create a console executable testing each method in the API.
Each source file is obviously added to a SCM so modifying files will automatically be reflected into the unit testing program;
All this (source updates, compilation, unit testing and doc generation) is added to our CI server (Jenkins) so that all libraries, for all unit testing programs are always recompiled from scratch;
The documentation for the library API is constructed with Doxygen using snippet from this program. This has a nice side-effect: changing the API will break your unit tests. So you have to fix your unit tests so your documentation is always up to date.
Related
I am trying to write unit tests for a larger, old project using GTest. The project compiles as a dll. Here is what the setup looks like: There are several projects inside the solution, and I am trying to add a Test Project to unit test on of the several projects.
As a proof of concept, I created a HelloWorld project, and a HelloWorldTest project in a different solution. To emulate my larger project, I changed the Configuration Type from .exe to .dll and ran into some errors. But these errors were resolved exporting classes/functions using __declspec(dllexport) along with including .lib in the project, and I am able to build and run the exe of the HelloWorldTest project.
I am trying to follow the same approach for my larger project by painstakingly adding EXPORT statements before classes/functions. However, I run into errors when I include required header files in the Test Project since the header file has other include statements which the Test Project does not understand about. For example, if I include "..\larger_project\custom_math.h" but custom_math.h has something like include "..\..\algo\somefile.h". (I've seen posts about referencing one project to another and have already done the same for my project.)
How do I resolve the issue of chained header file includes? I believe if I can resolve this, I should be able to create objects and start testing in my Test Project.
is there a better way to do this than adding EXPORT statements before every class/function?
I'm using VS Code Test Explorer with python extension on a project. It is awesome. If I change any source files, the relevant tests in Test explorer will be highlighted as out of date so I know I have to run them again to check everything is ok.
I'm trying to do the same thing with a C/C++ project and the Test Explorer Catch2 extension. I have a simple meson project file to build my test executable(s).
It works well in that my tests are discovered and I can run them, HOWEVER if I change a source file it the tests wont show as out of date to indicate that they need to be rerun.
I know this is a dependency issue with meson (or what ever build system that VS Code understands).
Is there a Test Explorer (or VS Code) way of for determining which exes are out of date and need building (tests and build in general)?
I have a solution which containes serveral projects (An MFC Application and the others are DLL projects). Is it possible to add another console application project (BOOST TEST) to unit test a specific DLL project, without modifying anything in the production MFC application and succeeding in building the whole solution?
I want only the test console application to run as a post build and then launching the prodution MFC application.
I wrote a series of blog posts on test-driven development in C++ that show you step-by-step how to do TDD in C++ with Visual Studio and Boost.Test. The steps would be nearly identical for your situation with the exception that your console test project depends on the DLL project instead of the static library project that I used in my article.
If I understand you correctly you want the build of the solution to compile and run the tests. If you say "build and run in the debugger" (F5), you want to compile all the code, run the tests and then run the application if the tests pass. This is not hard to do.
Set up the console unit test program as outlined in my blog posts and that will make the unit test project compile and run as part of the build. So if you say "build and run in the debugger" (F5) in Visual Studio, it will build the solution and then run the startup project, e.g. your MFC application. Since the solution contains the unit test console executable project, it will build that project. The unit test project has the post-build step to execute the tests, so the tests will run as part of the build.
Because your unit test executable depends on a DLL, you will need to make sure the DLL is found by the executable at run-time. You may need to add additional commands to your post-build step to copy the DLL to the necessary directory before running the test executable. You can verify this works properly by setting your unit test project as the startup project and running it in the debugger.
Double check in the configuration manager that all the projects are set to build for your combination of platform and configuration. Sometimes if you have customized these in your solution when you add a new project it isn't automatically checked to compile in the custom platform/configuration combination.
If this isn't working for you, then add a comment or edit your question to include more specifics about what isn't working.
Previously, when I had only Visual Studio 2010, my unit tests were executing fine.
Basically, my tests are composed of two files: UnitTests.dll and UnitTests.dll.config. Where UniTests.dll.config had a custom probing privatePath (e.g., Public;Extensions;Lib)
In order to execute, I used to follow this workflow:
1. I copied both files (i.e. UnitTests.dll and .config) to the folder were my application under test is located.
2. Open NUnit gui.
3. Execute the tests with ShadowCopy disabled, because my tests need to load the dlls from my application under test.
This was working fine!
After I installed Visual Studio 2012, the tests were not running anymore. And later, I figured out a workaround, but it is something that I don't want to use in my solution.
Now, I have to follow this workflow to make the tests running:
I copy both files (i.e. UnitTests.dll and .config) to the folder where my application under test is located.
I copy all the NUnit installation files (i.e. nunit-agent, nunit-console, etc.) to the folder where my application under test is located.
I change the probing privatePath from nunit-agent.dll.config in order to include the same paths from my UnitTests.dll.config.
Open NUnit gui which is located in my application under test folder.
Execute the tests with ShadowCopy disabled.
Note that I had to include steps 2 and 3 in order to run my unit tests. Somehow, I think nunit-agent.dll is not loading the probing privatePath from the config file of my test assembly.
Does anyone know why this is happening? Does anyone have a workaround where I don't need to change the nunit-agent.dll.config and copy the nunit installation files?
Thanks in advance.
Is there a way to set breakpoints and step through them using NUnit with a mixed project of native C++ and managed C++?
I have my SUT (Software Under Test) configured as a static library (native C++)
I have my unit test suite as a separate project configured as a dll that depends on my previously stated library. I also added said library as a reference to my unit test project.
My tests run fine in NUnit, breakpoints just don't work.
Again, is there a way to get the breakpoints to work with NUnit with Native/Managed C++?
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
$(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.
$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) to run the assembly directly. Note that this requires hard-coding part of the path, including the configuration.
If you would like to debug your tests, use the Visual Studio Debug | Processes… menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.