I have a DLL project in visual studio. I have lot of nice classes inside it that helps the dll. Most of these classes are not exported and used internally by the dll to accomplish the task.
Here is the deal, with visual studio test case project, I was able to test only the exported functions in DLL and not the individual classes.
Can you suggest any way/workaround to unit test all the individual classes in a dll project ?
There is no solid way, so any nicer way is appreciable.
Thanks in advance.
Put them in a utility dll, make them exported and test that or leave private (to the dll) and test them via the exported functions that use them.
One approach could be to build the project into a static library (.lib) instead of a DLL, and link the test project to that library. Doing so would allow the test project to access all of the classes in the library.
Of course, if you use this approach you would need to create a new, separate DLL that linked to the static library to perform the DLL exporting that's currently in place. This would likely require you to create wrapper classes/functions in the DLL that simply forward their invocations to the corresponding classes/functions in the static library.
I am answering my own question...
I managed to add them as existing item in a separate visual studio project and was able to build the exe. And I used google test framework to execute my tests. This way, I didn't change any code and at the same time I was able to test all the utility classes as an independent entity.
Thanks all
Related
I use MSVC2019 for two C++ projects:
APP is a dynamic link library.
TEST is the automated test project.
TEST does not only perform tests on the API part of the DLL, but also on some non-published methods of APP ("unit tests"). Those methods are made visible to the TEST project by linking against the .obj files of the APP project.
Keeping this list of .obj files up-to-date becomes tedious lately. I wondered if there's a way to provide the list of files as input text file to the MSVC linker (see "Configuration Properties" -> "Linker" -> "Command line" -> "Additional options"). A script could generate the list of files easily and just pass it to the linker by piping from stdin.
My first attempt failed, simply adding "< myLinkerArguments.txt".
Example:
PATH_TO_LINKER\link.exe /ERRORREPORT:PROMPT /OUT:"G:\testproject\test_d.exe" < myLinkerArguments.txt
Any ideas if and how that's possible?
Thank you for reading,
Paul
According to the Microsoft documentation, you could try the following but different approaches:
The unit tests call non-member functions that aren't exported from the DLL, and the DLL can be built as a static library: Change the DLL project so that it's compiled to a .lib file. Add a separate test project that references the project under test.
This approach has the benefit of allowing your tests to use non-exported members, but still keep the tests in a separate project.
or
The unit tests must call non-member functions that aren't exported, and the code must be built as a dynamic link library (DLL): Add unit tests in the same project as the product code.
See https://learn.microsoft.com/en-us/visualstudio/test/how-to-write-unit-tests-for-cpp-dlls?view=vs-2022 for more information.
I would build a version of the DLL that is identical in every respect but which (also) exports the additional functions you want to test. Linking these in as separate object files sounds dangerous since then you have two copies - one in the .OBJ file and one in the DLL - and that might very well lead to trouble.
A practical way to achieve this is via a macro, let's call it EXPORT_FOR_TESTING, which can be #defined appropriately in the project file that builds the DLL.
So create yourself additional configuration(s) in there, one of which #defines EXPORT_FOR_TESTING as __declspec( dllexport ) and the other one can then define it as empty. After that, just link your test app with the test DLL and you're done.
Lets say I have:
a static library project called "LIB"
a application project called "LIBAPP"
a application project called "APP"
a application project called "APPTEST"
When i add "LIB" to LIBAPP Project Dependencies, Visual Studio automatically links "LIBAPP" against LIB.
But when i add APP to APPTEST Project Dependencies, it doesnt.
Since i am doing unit tests of APP's classes in APPTEST, i have to link against APP, therefore i am currently manually linking against all *.obj files of APP (hundreds...)
Since i have to change the link targets of APPTEST everytime i add or remove a *.cpp file from APP, this isnt a nice solution.
So is there a way to force Visual Studio to do this for me automatically, like it does when adding a static library Project Dependency ?
You can't "link against APP", as you've discovered.
One solution is to put all of APP's code into its own library, leaving APP as single source file that runs a function in that library. The you can make APPTEST another single source file that links against the new APP library.
Making an application depend on another is useful for causing both apps to both be build (if necessary) when you hit Compile. If you have enough code in APP that you feel that you need to write unit tests for them, I think it would be best to break this code out into another library, and call it something like "LIBAPPUTIL" or some-such which depends on LIB, and APP will have to depend on both LIB and LIBAPPUTIL.
You have noble intentions. By putting the parts of LIBAPP into a separate library, you get a bunch of benefits:
You can build variations of LIBAPP that have different void main()s
You can build several LIBAPPUTILs, each of which test usage of different sets of dependent code.
You can have alternate implementations of LIBAPPUTIL that do not depend on LIB. If you're smart with how you use interface types (either C++ virtuals or C structures full of function poointers) you can completely abstract away APP's dependency on LIB.
Is there a tutorial/reference for creating an ActiveX DLL in Visual Studio 2008 C++ ?
I've got a DLL built with the DLLRegisterServer/UnregisterServer, and it's registered, but I'm having a little trouble figuring out what name to use to reference it (from a vbscript) and how to make sure my functions are exported correctly. Do I have to put my functions in a special class?
Thanks!
There are a lot of details to get right. Best thing to do is to use ATL and the built-in ATL object wizard. It auto-generates a bunch of files so that the IDL, type library, registration script, class wrapper and event proxies are all done correctly.
The component's ProgID is normally defined in the project's .rgs file.
+1 to nobugz
how to make sure my functions are exported correctly
Visual Studio contains OleView.exe. You can open your dll from it and see the list of props and methods.
As for tutorial, check here: ATL Concepts
I am developing a C++ library that I want to pass on to my team. The library has just one class with a bunch of methods.
So, I have developed the class definition file (X.cpp) and a corresponding class declaration file (X.h).
Here are my questions --
In Visual Studio 2005, whats is the most straight forward way to build this library as a DLL, such that I get the following files:
X.lib : which I can pass to my team so they can link against my library
X.dll : which I can pass to my team for run-time
Instead of a DLL, should I rather be going the static library way ?? If so, how do I go about doing this in Visual Studio 2005 & will this give me a X.lib file that I can pass on to my team ?
Any explanations or references are very welcome.
Thank you very much.
The easiest way to build a DLL, is New->Project->Win32 Console Application. Then on the dialog select DLL and select "Exports Symbols". This will synthesize a dll with a .h, and .cpp file which demonstrate how to export your classes. You can get rid of this .h/.cpp but first import your class add the appropriate #ifndef statements. Now as far as DLL versus Static library if its a single small class, that doesn't change particularly often you might be better off with a static library, its simple, its concise, it doesn't add another dependency which needs to be shipped with your product. A DLL is nice if the code in the .cpp file changes often (ie. the function implementations) because you can just swap in the new DLL.
From your description, it looks like you already have a Visual C++ project (correct me if I'm wrong). If so, when you go into project properties, under "General" you can find "Configuration Type" - switch it to "Static library" or "Dynamic library" as needed.
If you choose "Static library", then you will just get a .lib file that can be immediately used.
If you choose "Dynamic library", and you export any functions from your DLL (e.g. by marking them with __declspec(dllexport)), an export .lib will be generated automatically.
It's hard to tell which option is preferable without knowing the specifics of what you're doing. In general, I'd recommend defaulting to static libraries, because it's usually good enough, and there are more traps when dealing with DLLs (especially ones that export C++ symbols).
I think that, in most cases, a dll is a better choice than a static lib because your team will not have to recompile their code when you distribute a new version of your library.
I struggle with this too sometimes.. because I can't find where the elusive setting is within C++ Project Properties.. So I decided to jot it down for my own sanity as a blog post.
HTH
How are DLLs created out of C++ source code, and how are they used in other sources?
The DLL is a 'Dynamic Link Library' which works a lot like other libraries but is not linked with your executable application. At run time you can call specific functions for loading your DLL and executing its exported methods.
You can try creating a DLL yourself- create a project using visual studio and specify a DLL. This will create some of the base constructs for your project such as settings for your project to compile the DLL and also some base code for exposing methods, objects, or variables.
There are many walk through's to help you at this point: check here.
So, to summarize:
A DLL is a library which you can be loaded at runtime. This is a very flexible 'plug-in' model. Example: You can programmatically select and load different DLL at runtime. Each DLL can be a 'plug-in' to provide different functionality.
A DLL Has an entry point. Just like your Main function of your command line executable is the entry point, the DLL has an entry point function which is called when different events occur on the DLL such as loading, unloading, and more.
To use a DLL you must use the exported objects or methods of the DLL.
When Calling these exported functions from another application it is very important that you match compatible types! Also, make sure the calling conventions are compatible