The Boost Unit Test Adapter extension has been developed for the Visual Studio 2012, Visual Studio 2013 and Visual Studio 2015 Test Explorer window to allow integrated test execution of C++ projects utilizing the Boost Unit Test Framework.
In case of any issues please file an...
Great extension to run your Boost Tests from within Visual Studio. We use the Boost Test Library Unit Test Framework for our C++ development and the Boost Unit Test Adapter is really the best available Visual Studio extension to run those tests without the need to leave Visual Studio. Thanks :-)
I tried version 0.1 and it didn't even load the test list. Just downloaded and installed version 0.2, after few attempts it finally loaded the test list, but when I try to run all tests or any selection or debug a test it fails with the following message in output: ------ Run test started ------ An exception occurred while invoking executor 'executor://boosttestexecutor/v1': Object reference not set to an instance of an object. ========== Run test finished: 0 run (0:00:00.3314) ==========
For those suffering from an object reference not set error, you can download this extension via your browser then double click on it to launch the VSIX Installer. The extension will install correctly without error.
To uninstall you can use the Extensions & Updates dialog successfully.
this is an awesome extension - thank you so much!
I am struggling with a tiny detail in debug builds, so that debug code assertions can coexist with the Boost UTF. Our code is interspersed with a lot of FOO_ASSERT macros which, basically call _ASSERTE if _DEBUG is defined, otherwise evaluates to ((void)0). Nothing fancy.
So basically something like ...
FOO_ASSERT(nullptr != ptr);
if(nullptr == ptr) throw std::invalid_argument(...);
Within the unit test I want to catch the "invalid_argument" exception, but because of the FOO_ASSERT, the UTF catches a system error. On command line this can be circumvented with "--catch_system_errors=no". Using the adapter via the Test Explorer, one cannot pass the required parameter though (.runsettings does not support it) and using it as environment variable "BOOST_TEST_CATCH_SYSTEM_ERRORS=no" somehow failed.
So, it would be great to have a way to add this to the config options. Or would there be another/better way to achieve this? I don't want to recompile the debug code just because of unit testing.
This is a fantastic plugin and I was using it heavily on Visual Studio 2013. Now I have moved to 2014 for the support of C++14 and other stuff. It will be really really help to evaluate if we get this plugin support for evaluating.
Hello, Is there any momentum on supporting Visual Studio 2015? Having this plug-in will help in evaluating Visual Studio 2015 for my company's use. I am fine to take a developer release to test as well. Please let me know.
It took me a while to get it to run on Visual Studio 2015 Community Edition. Not sure if I missed something obvious. I shared my steps here in case they're of use: http://stackoverflow.com/a/32355135/5190279
Is there a way to get it to run using Platform Toolset v140? (i.e. Visual Studio 2015)
For Visual Studio 2015 you need to use the Boost libraries created for Visual Studio 2015 (libboost_unit_test_framework-vc140-mt-1_55 instead of libboost_unit_test_framework-vc120-mt-1_55).
- vc140 = Visual Studio 2015 (Platform Toolset v140)
- vc120 = Visual Studio 2013 (Platform Toolset v120)
Download the Boost sources and compile them for Visual Studio 2015. Then you can use the Boost Unit Test extension also with the Visual Studio 2015 compiler.
The versioning of Visual Studio (2015 = v140, 2013 = v120) is very confusing, I know ;-)
Hi, thanks for replying.
I tried to produce the binaries myself to get the v140 (visual studio 2015) but for some reason the files produced had no version associated with them (e.g. libboost_unit_test_framework-vc-mt-1_57), and I couldn't find precompiled binaries using version v140.
Will I encounter problems if my project is v140 but my boost test project is v120?
The binaries for Boost 1.59 are available for Visual Studio 2015: http://sourceforge.net/projects/boost/files/boost-binaries/1.59.0/
Here is a short description (for 64-bit) how to build the binaries for boost 1.xx for a certain Visual Studio version:
Download the sources of the desired boost version, unzip the file and go to the root folder where bootstrap.bat is located.
Run the following commands from command line:
2.) "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 [64-bit]
3.) "bjam --clean"
5.) "bjam -j4 --debug-symbols=on --build-type=complete toolset=msvc-14.0 threading=multi runtime-link=shared address-model=64"
to 5.) msvc-14.0 : defines the Visual Studio 2015 version
address-model=64 : defines the platform (32/64)
I hope this helps.
I've been enjoying this extension and it was key in my decision to use Boost.Test and TurtleMock at my company. I have an interest in ensuring this is a reliable and sustained project but unfortunately I haven't been able find any kind of publicly available homepage, issue tracker, or source code. Does any of this exist or is this page the only public resource?
That said, I do have an issue to report, fortunately it is easy to fix. The problem is that after creating a new Boost Unit Test Project the project fails to build. The problem appears to be an unset Platform Toolset.
Thank you for this extension, since we started with boost.test I've been using it almost every day.
Visual Studio 2013
Boost Test Runner Adapater 0.9.4
First of all, great extensions, it is really useful.
I am trying to integrate the boost test adapter to our build system. The unit tests are running fine in our developers machines.
The issue is when i follow (https://msdn.microsoft.com/en-us/library/ms253138.aspx) to add the adapter to the build system I get an 'Object reference not set to an instance of an object'. My assembly file specification points to the .exe generated by the boost test project. Does anyone has gone trough the process of integrating with TFS? Any thoughts?
I tested your adapter and it looks promising. All our tests are discovered but when I want to run tests it just outputs:
-- Run test started --
and then a few seconds later
-- Run test finished: 0 run
Since we use a pretty complex build system it would be nice to have a log file where your adapter tells me a bit more about what went wrong. Is there such a file and if yes where is it? Or do you have any idea what could be the problem?
Okay so I adjusted some environment variables and now most of the tests run. However I have one group of tests which use the BOOST_AUTO_TEST_CASE_TEMPLATE macro. These tests are nicely detected and even list a test case for each type which is great. But when I want to run them there is an error:
Boost Unit Test Adapter: Error while executing tests: StartIndex cannot be less than zero.
Parameter name: startIndex
I tried to reproduce the issue you described and can give you the following hints:
Using the following example code I was able to successfully execute the unit tests:
typedef boost::mpl::list<int, long, double> testTypes;
BOOST_AUTO_TEST_CASE_TEMPLATE( TypeTest, T, testTypes )
BOOST_REQUIRE_EQUAL( sizeof(T), unsigned(4));
Also, if you wrap the test case within a test suite, it works fine.
But it is important that you avoid using ifdefs because the parser, which is responsible for finding test cases within a source code file, is not able to handle ifdefs correctly.
If, for example, you use the following code snippet (the XXX is not set in the project properties)
// source code from above
the tests cases will be displayed in the test explorer (which is wrong), but they are not been "compiled into" the executable (which is correct), resulting in the error you described.
This is a known limitation of the adapter. We are working on a solution for that issue.
Thank you for the quick answer. Although the test file does not contain any ifdefs and I removed all ifdefs from the test fixture the same errors still occur. I looked through some of the included files and there are many ifdefs so I am not completely sure if this is the problem or not. Also all the testcases listed in the testexplorer are executed if I run the executable directly.
I will try again when you added support for ifdefs.
I get the 'StartIndex cannot be less than zero' error, when attempting to run a unit test that has nested test suites, example:
I already mentioned it earlier: the adapter does NOT support nested test suites. The reason for that limitation is that Visual Studio does not support displaying test trees with more than 1 child in the Test Explorer window, i.e. neither nested test suites (boost adapter) nor nested test classes (native test framework) can be displayed.
BOOST_AUTO_TEST_CAST_TEMPLATE doesn't work if the mpl list is a list of classes.
Say I have a class Foo
the test automatically generated name will come out as
But the parser reads it as
and then I get the dreaded "StartIndex cannot be < 0" when I try to run the test.
I have some tests that run for as much as an hour (stress testing) I have never seen one of them report in the test explorer taking more than 2 minutes (sometimes it says 1) and yet the logs for the test clearly show that it ran all the way through.
Would it be possible to have the full output of a test case?
If not then the first failure would be more helpful than last.
Test Name: my
Test FullName: mySuitemy
Test Source: <hide>.cpp : line 41
Test Outcome: Failed
Test Duration: 0:00:00.0000001
Result Message: three
Result StackTrace: <hide>.cpp line 45
Is there a way to get all the failures?
Even if the first two are not critical, there may be a reason for the order and it makes sense to fix the first one first, doesn't it?
I have just a few tests in my project (300+) and the performance of running them is prohibitively bad - when running as a post build step I don't even notice the tests executing as it takes <1s and using this extension with run all tests option the same tests take over a minute.
Another performance issue is that the whole solution is build rather than the unit test projects - in my case this means a very extended link duration which again does not exist when running the tests as a post build step.
Is there any chance for this to improve? Am I doing anything wrong?