I am working on making my application be implemented using more of a plugin system.
This results in me having my main application EXE (or DLL, but I don't think it needs to be), which exports all the symbols for the core functionality.
I then have plugin DLL's that only need to export a simple IPlugin* createPlugin(); so the plugin can be dynamically loaded at run time, and link against the main application for utility and class methods (I do not plan to wrap them all in virtual interfaces to work via the IPlugin, and at any rate there are things that really benefit from inlining).
Getting this correctly built is simple enough, build the app to get the import lib, then build the plugins.
however the problem I would like to solve is the simple one that if I am in the MSVC IDE and have the app as the start up project, and run it ("Start [Without] Debugging") I want to ensure that any plugin projects get fully built first (just to avoid dev mistakes that end up with old code being run).
You could set the startup project to a pseudo-project that depends on all the others, and has its "executable to be debugged" in the project configuration set to the output of the main application.
Tools -> Options -> Projects and Solutions -> Build and Run -> (uncheck) Only build startup projects and dependencies on Run.
Related
I'm confused on how I'm supposed to use the QtTest FrameWork inside a Library project (Windows). I have created a library project and added some tests, but I had a lot of issues trying to run the tests. The key to solve my problem was to set:
TEMPLATE = app
However, I'm making a lib... also app makes an exe, not a dll. I really hope that it's not intent to have to change the project file manually to 'app' when testing and changing to 'lib' for actual building the library. This seems unproductive.
So, what's up with QtTests inside library projects?
Thanks
I'm working on a game which has different "modules" that I am developping on separate projets for now, with VS2010.
So far I have each project in its own solution, and the main.cpp file is used to basically initialize and do some quick tests on my project, that I change very often.
Is it possible (and how) to have 1 solution regrouping several projects while at the same time having also one "main" function per project that I could launch independently of the other projects to test one project specifically?
Here's what I would do:
Put all your projects in one solution. There is some button or menu option somewhere to Add a Project to a solution. The advantage of this is that you can be editing multiple projects at once and Visual Studio will automatically rebuild everything that needs to be rebuilt when you compile.
All your reusable code (code used in more than on executable) should be divided up into projects that compile to DLLs.
For each executable you want to generate, you should have a project that compiles to an executable and references/links to the DLLs it depends on. Each executable project will have its own main function which runs when you run the exe.
If you want to have a way to test your DLLs without generating an executable, you can make an entry point in your DLL and run it using rundll32. This would be good for developers testing your DLLs, but I would never tell a user to use rundll32.
The build configurations are specific of each project, including which class contains the main method -IIRC, you can define several main in your project and define which one should be called through project configuration-.
I am wondering what would be an effective way to organize C++ projects and classes that are going to be unit tested. I have read many SO posts related to unit test but couldn't find practical examples.
Here are some ways I have collected:
Method A
Project A: Application (.exe) project that "include" the classes from Project C
Project B: Unit test (.exe) project that "include" the classes from Project C
Project C: Static library (.lib) project that keeps all classes that Project A uses
Method B
Project A: Application (.exe) project with all classes inside itself.
Project B: Unit test (.exe) project that "links" to classes in Project A
Method C (from Miguel)
only one project, with three configurations:
Debug: builds your Application .exe in debug mode.
Release: builds your Application .exe in release mode.
Test: builds the unit test framework, replaces your app's main() with the unit testing main()
Which is the more appropriate way? Do you have any other suggestions?
I have previously used the first method quite well. Have most of your code in a static library project, have the main executable project just contain the main function, and have your tests and the test main function in a third project. The two executable projects will link to the static library and reuse the code.
The main benefits in doing it this way are:
The code that is being tested is the exact same build as is used in your application.
You can test both the debug and release configurations to ensure that both work as expected. (You can extrapolate debug and release for any configurations that you might require.)
Build time is minimised since the same built library is used in both executable projects.
Can have the build system build both the test and main executable at the same time, and also run the test executable after building.
There's not that much difference actually, as you can always compile the exe as a static library and link against the unit tests. Conceptually, Method A is slightly cleaner, but there's nothing preventing you from using Method B. It basically boils down to your build system what is easier to do.
I don't think you'll gain much by moving the classes of your application to a static library. You should also consider that you may want to modify your classes when you compile them for testing, for example by adding additional convenience methods that are not necessary for the application, so in the end putting the classes in a library may not help at all since you will need a special version of these classes when running tests.
I would like to suggest the following as a better option than your methods A and B:
METHOD C
only one project, with three configurations:
Debug: builds your Application .exe in debug mode.
Release: builds your Application .exe in release mode.
Test: builds the unit test framework, replaces your app's main() with the unit testing main()
If you think you need to, you can split the Test target into Debug and Release as well.
I have a solution consisting of several library project and one application project.
I want to create a separate application test project. However, my problem is how I can write test for the application project since I can't link to it? I've added the application project as a reference in "Common Properties", but I get LNK1120 probably because the application project doesn't generate a lib file to link.
How do I create a separate test project for a project with application as configuration type?
I can think of three solutions to this - none 100% as clean as I'd prefer.
Compile test code into a test library that is conditionally linked to the application program, and is driven by test input to the program. So in effect you use your own app as the test driver
Make you application a shell only and put all unit tested code in to a library that can also be linked into the test app.
same as the last one, but compile the code in the library into the app in the application build, but into the library for the test build.
The second would be my choice.
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.