Unit Test Output & Project Structure Advice — CMake + Google Test Framework
I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:
ProjectFolder
-CMakeLists.txt
/build
/include
-all my .h files
/src
-CMakeLists.txt
-all my .cpp files
/tests
-CMakeLists.txt
/gtest
-Google's CMakeLists.txt
/mocks
-CMakeLists.txt
-cpp and h files for mocks
In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.
What I eventually get are several executables: objA_unittest, objB_unittest, etc
A few things:
To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?
I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.
Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?
Thanks very much in advance.
cmake googletest
add a comment |
I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:
ProjectFolder
-CMakeLists.txt
/build
/include
-all my .h files
/src
-CMakeLists.txt
-all my .cpp files
/tests
-CMakeLists.txt
/gtest
-Google's CMakeLists.txt
/mocks
-CMakeLists.txt
-cpp and h files for mocks
In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.
What I eventually get are several executables: objA_unittest, objB_unittest, etc
A few things:
To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?
I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.
Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?
Thanks very much in advance.
cmake googletest
add a comment |
I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:
ProjectFolder
-CMakeLists.txt
/build
/include
-all my .h files
/src
-CMakeLists.txt
-all my .cpp files
/tests
-CMakeLists.txt
/gtest
-Google's CMakeLists.txt
/mocks
-CMakeLists.txt
-cpp and h files for mocks
In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.
What I eventually get are several executables: objA_unittest, objB_unittest, etc
A few things:
To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?
I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.
Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?
Thanks very much in advance.
cmake googletest
I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:
ProjectFolder
-CMakeLists.txt
/build
/include
-all my .h files
/src
-CMakeLists.txt
-all my .cpp files
/tests
-CMakeLists.txt
/gtest
-Google's CMakeLists.txt
/mocks
-CMakeLists.txt
-cpp and h files for mocks
In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.
What I eventually get are several executables: objA_unittest, objB_unittest, etc
A few things:
To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?
I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.
Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?
Thanks very much in advance.
cmake googletest
cmake googletest
edited Aug 31 '11 at 21:44
Landon
asked Aug 31 '11 at 19:30
LandonLandon
3411210
3411210
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
- It is actually a recommended cmake practice called out-of-source build
- AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.
- I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:
Add following lines into your top level CMakeLists.txt
(before adding any tests):
add_custom_target(test)
macro(run_test test_target)
add_custom_target(${test_target}_runtest
COMMAND ${test_target} #cmake 2.6 required
DEPENDS ${test_target}
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
add_dependencies(test ${test_target}_runtest)
endmacro()
Next for each test add a single line to append your test to the test
target:
#add_executable(mytest ${mysources})
run_test(mytest)
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
add a comment |
Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262370%2funit-test-output-project-structure-advice-cmake-google-test-framework%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
- It is actually a recommended cmake practice called out-of-source build
- AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.
- I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:
Add following lines into your top level CMakeLists.txt
(before adding any tests):
add_custom_target(test)
macro(run_test test_target)
add_custom_target(${test_target}_runtest
COMMAND ${test_target} #cmake 2.6 required
DEPENDS ${test_target}
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
add_dependencies(test ${test_target}_runtest)
endmacro()
Next for each test add a single line to append your test to the test
target:
#add_executable(mytest ${mysources})
run_test(mytest)
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
add a comment |
- It is actually a recommended cmake practice called out-of-source build
- AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.
- I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:
Add following lines into your top level CMakeLists.txt
(before adding any tests):
add_custom_target(test)
macro(run_test test_target)
add_custom_target(${test_target}_runtest
COMMAND ${test_target} #cmake 2.6 required
DEPENDS ${test_target}
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
add_dependencies(test ${test_target}_runtest)
endmacro()
Next for each test add a single line to append your test to the test
target:
#add_executable(mytest ${mysources})
run_test(mytest)
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
add a comment |
- It is actually a recommended cmake practice called out-of-source build
- AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.
- I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:
Add following lines into your top level CMakeLists.txt
(before adding any tests):
add_custom_target(test)
macro(run_test test_target)
add_custom_target(${test_target}_runtest
COMMAND ${test_target} #cmake 2.6 required
DEPENDS ${test_target}
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
add_dependencies(test ${test_target}_runtest)
endmacro()
Next for each test add a single line to append your test to the test
target:
#add_executable(mytest ${mysources})
run_test(mytest)
- It is actually a recommended cmake practice called out-of-source build
- AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.
- I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:
Add following lines into your top level CMakeLists.txt
(before adding any tests):
add_custom_target(test)
macro(run_test test_target)
add_custom_target(${test_target}_runtest
COMMAND ${test_target} #cmake 2.6 required
DEPENDS ${test_target}
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
add_dependencies(test ${test_target}_runtest)
endmacro()
Next for each test add a single line to append your test to the test
target:
#add_executable(mytest ${mysources})
run_test(mytest)
answered Sep 1 '11 at 0:29
Andrey KamaevAndrey Kamaev
24.5k57378
24.5k57378
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
add a comment |
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
3
3
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
– DLRdave
Sep 1 '11 at 11:24
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
– Landon
Sep 2 '11 at 19:02
add a comment |
Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
add a comment |
Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
add a comment |
Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.
Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.
answered Sep 1 '11 at 4:22
Sergei NikulovSergei Nikulov
4,2151730
4,2151730
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
add a comment |
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
– Kurt Schwehr
Nov 18 '12 at 19:54
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
– Sergei Nikulov
Nov 19 '12 at 8:24
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
@KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
– Sergei Nikulov
Dec 3 '12 at 9:37
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262370%2funit-test-output-project-structure-advice-cmake-google-test-framework%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown