I am trying Unit test using Gtest.
I am creating a another project that has file from the original project (By linking) that is to be tested. In the new project I then create Fake Implementation and Mocks of the additional dependencies of the function or Unit I want to test. In the file from the original project I am using #ifdef to include original dependencies or the fake implementation
The problem I am facing is I need to compile the files in particular order so that the fake implementations are included when test project is build.
I am using MCUXpresso on Windows 10 with MinGW, GNU Builder
Anticipating any workaround or way to get control over order in which files are compiled.
#ifdef IsTesting //This is part or original project, original header files
#include "Fake_dependency"
#else
#include "Original_Dependency"
#endif
Then in the new project I define
#define IsTesting true // Part of Test_Project, followed by other code for testing
when I compile the new project or test project I need this file having this variable defined to be compiled first or earlier than the file that I am linking from the Original project
Instead of defining IsTesting in your test code, you can add the definition to your Build Configuration for the test project.
Go to Properties -> C/C++ General -> Paths and Symbols -> Select the appropriate language (GNU C++) and add "IsTesting" (without any value)
If you want Eclipse to get the compiled code right (not compiled code is gray) you will have to toggle
Properties -> C/C++ General -> Indexer -> Use active build configuration as well
Related
I have started a new solution under VS that has both a managed, UWP code project and a native project. The compiler compiles the native code and delivers a .lib file just fine. When compiling the managed code, the compiler compiles the native code again -- as managed code and spits out errors.
I have another solution that use to work and I have tried to replicate the settings. After a day of comparing the property settings, I cannot figure out why it's doing what it's doing.
Ideas for where to look?
_____ New below_____
I have started a new solution an project and replicated everything. Here's what I've learned.
First, the compile order is different -- there was a missing stdafx.h file and the errors went from infinite to just 25. They are now related to one file, MotionBase. The native project compiles just fine, then the managed project compiles and it barfs on MotionBase. This code sample gives errors "'MotionBase': is not a member of 'BallLib'" and"'input': unknown override specifier".
#pragma once
#include "stdafx.h"
#include "FiniteDiffHelpers.h"
#include "MotionBase.h"
#include "MultiVarSolver.h"
namespace BallLib {
class PathFinderHelper : public FiniteDiffHelper
{
public:
PathFinderHelper();
Line locs;
BallLib::MotionBase output;
MotionBase input;
.....
PathFinderHelper compiled fine in the native project. There are no errors in MotionBase. MotionBase is part of BallLib. Intelisense gives no errors in PathFinderHelper.
Ensure the stdafx.h files are properly inserted in the code. The build order is different so you may get trapped.
Include (#include) the native stdafx.h in the managed pch.h file.
Not all the relevant settings are in the project properties dialog. Also check the properties non-modal window, particularly with the project-to-project reference selected inside Solution Explorer.
There you will find a setting named "Use Library Dependency Inputs" which causes the main project to include the individual source files from the library project, instead of the static library. Make sure this is set to False.
I am writing my own C++ project library in visual studio (couple of projects that consist of *cpp, *.h files, NOT an actual .lib file). Each of these projects is located in single Visual Studio "solution".
When I needed to use a code from one project in another, I just copied it. But that was short term solution. Now my library has grown both in size and functionality, and because of code duplication I ended up with dozens of different versions of the same file.
That single solution serve me as a playground // test ground for new ideas. I am developing projects not libs. Currently it holds about 50 projects.
I am working on visual studio 2015.
Lets say I have setup like this:
DataIO project located in */Solution/#DataInputAndOutput/DataIO/DataIO.h
consist both of DataIO.h and DataIO.cpp
Foo project located in */Solution/#Foo/Foo/Foo.h
consist both of Foo.h and Foo.cpp
DataIO.h:
#pragma once
#ifndef __DATA_IO_H__
#define __DATA_IO_H__
// ...
extern FILE * const logFile;
// Bunch of function declarations
#endif // !__DATA_IO_H__
I know that this is not a "Minimal, Complete, and Verifiable example" but my problem lies in logistic of things, not things themselves. And I believe that my description is sufficient.
Problem #1: In Foo.cpp I #include "DataIO.h" (with is possible because i added additional include directories in Foo project setup) But whenever I try to compile Foo I am given following error: unresolved external symbol for every function declaration inside DataIO.h and that one external variable. How Can I Fix this problem? Do I need to create a DataIO.lib to keep things straight?
I tried to add DataIO.h and DataIO.cpp into Foo project directly (NOT copy it, just add it into project) but that seems like a bad idea...
I recommend trying out the new "Shared Items Project" in VS2015+. A Shared Items Project is literally just a set of files. The project itself doesn't build anything. In fact, there are no (or almost no) compilation or linkage settings in a Shared Items Project -- those settings come the the project that references the Shared Items Project. When you reference a Shared Items Project from some other project FOO, the build of FOO happens as if the files of the Shared Items Project are items of the referencing project.
Short of that, you can set up your shared projects to build .libs and then use Project References within Visual Studio to automatically set up the linkage. I think you have to manually set up the include paths when doing this, though.
The best way to do this is to factor out common code into a library so the common code resides in one place. And then have your projects use the library - via an include file and linking with said library.
Scenario 1
A solution SolA contains only 1 project named PrjA.
PrjA is a Win32 console application, the compilation result is PrjA.exe.
How shall I split the source code files in PrjA into PrjA1 and PrjB, so that the management of the source code is easier, while the compilation result, PrjA1.exe, will be almost the same as PrjA.exe?
For example, I have PrjA :-
PrjA has 300 .cpp files.
PrjA.exe sizes 400KB.
I hope to split PrjA into 2 projects :-
PrjA1 has 200 .cpp files
PrjB has 100 .cpp files.
PrjA1.exe is also around 400KB.
I'm not sure how to setup PrjB or what will be its compilation result.
Assume PrjB compiles to PrjB.DLL, sized 100KB, I hope PrjA1.exe will somehow embed PrjB.dll inside itself. Thus the size would be 400KB.
I don't want a 300KB PrjA1.exe, which will dynamically link to 100KB PrjB.dll in runtime.
Question: How shall I set PrjB, and how shall I set the link between PrjA1 and PrjB?
Scenario 2
Same as Scenario 1, just this round PrjA's compilation result is a windows DLL, named PrjA.dll, how shall I split PrjA into PrjA1 and PrjB?
The development environment is Visual Studio 2013 under windows 7 64-bits, but the compilation results are 32-bit.
This is how you move existing code into static library. I use VS2015, it should be the same with VS2013, but I can't check that. I start with the following solution structure:
First thing to do is to add new project to the solution.
File -> Add -> New project -> Win32 Project
Check Static library and uncheck precompiled header
Then click Show all files icon in the solution explorer for both projects. This turn filters off and shows project folder as it is. It should look like this:
Drag and drop all needed files from one project to another:
Now reference your library. Uncheck Show all files icon to show References. Right click -> Add reference and check your static library project:
Last thing to do is to add include directory to the project that uses the library. This is done in project properties. Be sure to check All configurations and All platforms:
That's it. Now when you build your solution, VS builds your static library, builds your main project and links them together. The result should be identical as if everything is in the same project.
I have two projects. One called projectA and the other called projectA-tests.
The first project is my actual project, and the second project contains GoogleTest unit tests for classes in projectA.
I have coded one very simple unit test so far and everything builds OK. Note that this first simple test depends on a single .h file of projectA that has only a static class method defined in the same .h file (no .cpp file). It's actually a "StringUtils" class with methods like ::startsWith() and so on.
After adding a second test I'm having linking problems. This second test depends con a Class of projectA that is declared in a .h file and defined in a .cpp file. I'm getting an undefined reference regarding this Class, trying to build this second test.
projectA-tests compiler settings are configured to include projectA/src in project -> properties -> C/C++ build -> settings -> C++ compiler -> includes. (I guess this is why the first compiles ok, because it only requires a .h file which is covered by this "includes" setting).
What I don't know is how to configure the C++ linker in projectA-test to include all .o files of projectA in the linkage process.
I'm more experienced in Java, and the equivalent would be simply adding the other project source folder as dependency of the build path. Whay is Eclipse CDT's C++ equivalent?
Thanks!
I have a Visual Studio solution organised like this:
ProjectA // A static library I'm working on
ProjectB // A static library containing UnitTest++ test suites for ProjectA
ProjectC // An executable test runner which links to ProjectA and ProjectB
ProjectB contains two files which look like this:
// RunTests.h
#ifndef RUNTESTS_H
#define RUNTESTS_H
#include "UnitTest++.h"
int runAllTests();
#endif
and this:
// RunTests.cpp
#include "RunTests.h"
int runAllTests()
{
return UnitTest::RunAllTests();
}
As well as several files containing test suites e.g.:
// FooTests.cpp
#include "RunTests.h" //
#include "Foo.h" // From ProjectA
TEST(SomeTest)
{
CHECK(true);
}
ProjectC consists of a single file:
// main.cpp
#include "RunTests.h" // from ProjectB
int main()
{
return runAllTests();
}
The reason I have the tests and the test runner separated, is that I have another project which uses the same tests to analyse code coverage, which I need to keep separate as it is not cross-platform, whereas the test runner is.
The issue is, that when I compile and run ProjectC, no tests are actually run (UnitTest++ runs, but with zero tests). This is because ProjectC does not reference any symbols relating to the tests from ProjectB, so the linker doesn't link the object files from ProjectB.lib.
It is my understanding that if ProjectB was an executable, I would not have this issue (presumably because the linker would link all the object files), as per the documentation:
The general idea is that you keep one Main.cpp file with the
entry-point which calls RunAllTests().
Then you can simply compile and link new .cpp files at will, typically
one per test suite.
Each of the Test*.cpp files will contain one or more TEST macro incantations with the associated
test code. There are no source-level dependencies between Main.cpp and
Test*.cpp, as the TEST macro handles the registration and setup
necessary for RunAllTests() to find all tests compiled into the same
final executable.
How can I resolve this problem without having to declare all the tests in header files that ProjectC can see (which would kill UnitTest++'s ease of use)? One possibility I've noticed in Visual Studio is:
Project Settings > Configuration Properties > Linker > Input > Force Symbol References
However it would be rather tedious to have to add every single symbol, every time I write a new unit test. Is there some way I can force it to include the entire contents of ProjectB.lib? Or perhaps some code-based solution?
EDIT: What I'm looking for is something like this but for Visual Studio.
I was trying to use UnitTest++ the same way you've described and ran into the same problem. I ran across a suggestion in another forum that seems to work for my unittest executable (i.e. ProjectC).
For ProjectC:
Project Settings > Common Properties > (select ProjectB) > Use Library Dependency Inputs: True
This worked for me. I think what this does is effectively link any object files from ProjectB into ProjectC (as opposed to linking the library).