I have a library inside which there are some testing programs written using Boost.Test. The test files don't have #define BOOST_TEST_DYN_LINK or #include <boost/test/included/unit_test.hpp>. They only have #include <boost/test/unit_test.hpp>. So the main() function isn't there implicitly.
Now I have to debug some library functions which have been used in the test cases. Given that I cannot add or change anything in the test programs, how can I invoke the test programs under a debugger ?
Create a test runner (e.g. main_test.cpp) and link your library against that.
# main_test.cpp
// --- Boost Includes ---
#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>
Invoking the resulting executable should run your tests. You can then debug individual tests by invoking the runner with ./myrunner --run_test='some_testsuite'/../'some_testname'.
Related
I'm creating unit tests in PlatformIO using Unity with the ArduinoFake library
I'm trying to test a piece of code that uses the Wire library
When I try to run the unit test (env:native), it complains that the build cannot find <Wire.h>
my platformio.ini file has the following...
[env:native]
lib_deps = fabiobatsilva/ArduinoFake#^0.3.1
If I comment out #include <Wire.h> in the code under test, then the unit test works, so I assume the <Arduino.h> supplied by the ArduinoFake library also provides the necessary references for Wire - but then the build for the Uno platform fails because there's no reference to Wire.h
Anyone used ArduinoFake to test code using Wire? - how did you resolve this?
Ok - found a solution - wrapped the include in an #ifndef
Not pretty, but does the job
#ifndef PIO_UNIT_TESTING
#include <Wire.h>
#endif
I'm using doctest for the tests in my C++ project.
I would like to put the test code alongside my implementations, as the library says is possible, but I can't seem to figure out what to do with the doctest implementation code.
I have a doctest.cpp file that looks like this:
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include "doctest.h"
A main.cpp that looks like this:
#include "thing.h"
int main(int argc, const char *argv[]) {
do_thing();
}
thing.h is self-explanatory, but thing.cpp looks like this:
do_thing() {}
TEST_CASE("Test thing") {
CHECK(1 == 1);
}
CMake is used to create two executables, a Tests executable and a Main executable.
If I don't include doctest.cpp in my project sources for Main, I get undefined reference errors because it can't find a definition for all the testing stuff in doctest.
However, if I do include it I get errors because there are multiple main() functions in one target.
I can't find any info on this in the doctest documentation.
How are you meant to get around this?
The author of the library gave a good response in this issue:
DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN implements the test runner and also defines a main() function.
DOCTEST_CONFIG_IMPLEMENT implements ONLY the test runner.
If you define your own main() then you should use DOCTEST_CONFIG_IMPLEMENT - have a look at the relevant docs.
You will need the test runner implemented in your main executable (that means doctest.cpp) since you are writing your tests alongside your production code.
You can also define DOCTEST_CONFIG_DISABLE when building the main executable so tests are written in the production code but aren't compiled (you will still need doctest.cpp so it all links). This way you won't need to #ifdef the tests.
You could also entirely remove the test executable and use the main executable for running the tests - docs.
I went with the first option of writing my own main() function.
I encountered the same problem and one workaround is to add -DDOCTEST_CONFIG_DISABLE to the compiler flags when you compile Main.
I'm trying to get into testing in c++ using VS2015 with Boost, following this guide on docs.microsoft.
I've installed the boost unit test adapter from the marketplace.
If my understanding is correct, I should now be able to see my boost test cases in the test case explorer within VS2015 but somehow I don't see any of them. Building the project runs just fine and depending on whether my test cases are valid or not, the program exits with 0 or 201.
My project has a single .cpp file with the following contents:
#define BOOST_TEST_MODULE MyTest
#include <boost/test/included/unit_test.hpp>
BOOST_AUTO_TEST_CASE(my_boost_test)
{
BOOST_CHECK(0==0);
}
BOOST_AUTO_TEST_CASE(my_boost_test2)
{
BOOST_CHECK(0==1);
}
If you download the latest version of Google Mock (1.7.0) there are project files for VS2005 and 2010! The project to test is written in VS2008,so I opened the VS2005 file and converted it for VS2008 and compiled with
Multi-threaded Debug (/MTd)
Dynamic Library (.dll)
In the test solution:
Project to test:
Configuration type: Dynamic Library (.dll)
Runtime library: Multi-threaded Debug (/MTd)
UnitTest project:
#include <iostream>
#include "gmock/gmock.h"
#include "gtest/gtest.h"
int main(int argc, char **argv)
{
::testing::InitGoogleMock(&argc, argv);
return RUN_ALL_TESTS();
}
Additional Library Directories: ..\..\gmock\msvc\2005\Debug
Additional Dependencies: gmock.lib gmock_main.lib
Runtime library: Multi-threaded Debug (/MTd)
If I run the UnitTest project I get following error:
Windows has triggered a breakpoint in Program_UnitTests.exe.
This may be due to a corruption of the heap, which indicates a bug in Program_UnitTests.exe or any of the DLLs it has loaded.
in xmtx.c:
_RELIABILITY_CONTRACT
void __CLRCALL_PURE_OR_CDECL _Mtxunlock(_Rmtx *_Mtx)
{ /* unlock mutex */
LeaveCriticalSection(_Mtx);
#ifdef _M_CEE
System::Threading::Thread::EndThreadAffinity();
#endif
} // <------- STOPPED HERE
#endif /* !_MULTI_THREAD */
What is wrong here? Thank you for any help!
Super-short answer: compile googlemock as a static library instead of a dll; that might fix your problem.
Much longer answer:
Problems like this are typically the result of mismatched compiler settings. These kinds of problems are a pain to diagnose, which is a large part of the reason for the following guidance given in the googletest FAQ:
If you compile Google Test and your test code using different compiler flags, they may see different definitions of the same class/function/variable (e.g. due to the use of #if in Google Test). Therefore, for your sanity, we recommend to avoid installing pre-compiled Google Test libraries. Instead, each project should compile Google Test itself such that it can be sure that the same flags are used for both Google Test and the tests.
This applies equally to googlemock. Basically, they're suggesting that you compile the googletest & googlemock source code alongside your own code to avoid this problem. They also make this quite easy: check out the fused-src directory of the gmock distribution for a voltron .cc file and the corresponding headers, gmock.h and gtest.h.
If you'd like to continue linking against a completely separate library, you'll need to verify that all of the compiler settings match in the VS project. Basically you'll need to check every single configuration in the properties dialog, paying special attention to the toolset, exceptions, preprocessor definitions, RTTI, etc.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
The Boost.Test documentation and examples don't really seem to contain any non-trivial examples and so far the two tutorials I've found here and here while helpful are both fairly basic.
I would like to have a master test suite for the entire project, while maintaining per module suites of unit tests and fixtures that can be run independently. I'll also be using a mock server to test various networking edge cases.
I'm on Ubuntu 8.04, but I'll take any example Linux or Windows since I'm writing my own makefiles anyways.
Edit
As a test I did the following:
// test1.cpp
#define BOOST_TEST_MODULE Regression
#include <boost/test/included/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(test1_suite)
BOOST_AUTO_TEST_CASE(Test1)
{
BOOST_CHECK(2 < 1);
}
BOOST_AUTO_TEST_SUITE_END()
// test2.cpp
#include <boost/test/included/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(test2_suite)
BOOST_AUTO_TEST_CASE(Test1)
{
BOOST_CHECK(1<2);
}
BOOST_AUTO_TEST_SUITE_END()
Then I compile it: g++ test1.cpp test2.cpp -o tests
This gives me about a bazillion "multiple definition of" errors during linking.
When it's all in a single file it works fine.
C++ Unit Testing With Boost.Test
(permanent link: http://web.archive.org/web/20160524135412/http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/)
The above is a brilliant article and better than the actual Boost documentation.
Edit:
I also wrote a Perl script which will
auto-generate the makefile and project
skeleton from a list of class names,
including both the "all-in-one" test
suite and a stand alone test suite for
each class. It's called
makeSimple and can be downloaded
from Sourceforge.net.
What I found to be the basic problem is that if you want to split your tests into multiple files you have to link against the pre-compiled test runtime and not use the "headers only" version of Boost.Test. You have to add #define BOOST_TEST_DYN_LINK to each file and when including the Boost headers for example use <boost/test/unit_test.hpp> instead of <boost/test/included/unit_test.hpp>.
So to compile as a single test:
g++ test_main.cpp test1.cpp test2.cpp -lboost_unit_test_framework -o tests
or to compile an individual test:
g++ test1.cpp -DSTAND_ALONE -lboost_unit_test_framework -o test1
.
// test_main.cpp
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE Main
#include <boost/test/unit_test.hpp>
// test1.cpp
#define BOOST_TEST_DYN_LINK
#ifdef STAND_ALONE
# define BOOST_TEST_MODULE Main
#endif
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(test1_suite)
BOOST_AUTO_TEST_CASE(Test1)
{
BOOST_CHECK(2<1);
}
BOOST_AUTO_TEST_SUITE_END()
// test2.cpp
#define BOOST_TEST_DYN_LINK
#ifdef STAND_ALONE
# define BOOST_TEST_MODULE Main
#endif
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(test2_suite)
BOOST_AUTO_TEST_CASE(Test1)
{
BOOST_CHECK(1<2);
}
BOOST_AUTO_TEST_SUITE_END()
I don't know what else you really need than what's in the later tutorial. I've done everything I need to in just that way. Not sure I understand your description either.
One thing that you might be asking for is the ability to have more than one .cpp file in your test program. That's as simple as only defining BOOST_TEST_MODULE in one of those .cpp files. We have a "driver.cpp" file in all our test programs that just defines that and includes the unit test header. All the rest of the .cpp files (scoped by module or concept) only include the unit test header, they do not define that variable.
If you want to both be able to compile them together and compile them separately then you could use your own -D variable to define BOOST_TEST_MODULE or not.
If you're looking for a way to run a bunch of test programs in one single run and get a report then you could look at the automake method of doing tests or, better yet, the CMake method (CTest). Pretty sure you can use CTest from your own makefile if you insist.
When I only start with Boost.Test the following article with source code was very helpful:
Boost test setup and usage