I've been studying C++ for a while, but this is the first time I'm into a C++ project (a pet configuration parser library). I'm using the Google C++ Testing Framework to test this. But I don't know if I'm doing it right.
Currently, I've ripped off some parts of this Google test library and put it into my projects Test/googletest directory. It works OK, but I wonder if this is how I'm supposed to do this. I'm including the source code of the testing framework in my project and it will be released with my code. This makes me feel uncomfortable.
I wandered through some C++ projects on GitHub, trying to see how other people deal with this. Some have custom framework-lets, and most solve the whole problem with not testing the code at all.
I wonder if I'm taking this right, or otherwise how can I adopt a testing method that will both keep the framework out of my source tree and let me release my code with tests buildable and executable by the user?
Concerning your build, you're doing it right. The gtest readme explicitly states that building gtest (you can pack a libgtest.a from the two object files) along with your project is the prefered way to do it.
Concerning the distribution:
Ideally, you could have your build tool (make, CMake, etc) check out / fetch the required gtest version from its own repository. But I don't think there is much harm if you add an "external" folder to your project and include stuff like gtest in your own repository.
Related
I’ve got a project that needs to use the Nash Equilibrium solving capabilities of Gambit-Project
This is a performance critical application, so I have to somehow link my codebase with Gambit.
My actual use case sounds simple to me. There is one executable in the folder that has all the top level functions that I need.
The problem is that I am new to Cmake, and C++ in general. Additionally, Gambit is a very mature project that does not use Cmake; Instead, it uses its own make file which is quite difficult to parse.
My project is here: https://github.com/baskuit/surskit/blob/master/CMakeLists.txt
The CMakeLists.txt is very rudimentary (and half commented out this commit)
And Gambit project is here: https://github.com/gambitproject/gambit
with the required source file here: https://github.com/gambitproject/gambit/tree/master/src/tools/enummixed
I’m hoping that there is someway to link these two projects without delving into that heinous makefile.
I want to use Boost Test to unit test my code in Visual Studio 2010. I've downloaded and built the latest version of the library.
I've read a lot on the subject here and elsewhere on the internet and people seem to suggest having a second project within your solution exlusively for your tests.
Fine, sounds good. I'm having trouble actually setting this up however. I've yet to find a clear explanation of the best way to set this up.
Do I need to use a Project Reference to make my unit test project reference my main project?
If so, do I still need to add the Include & Source directories of my main project in the properties of my unit test project? If so, what's the advantage of using the Project Reference in the first place?
Do I have to have my main project output a library for my unit test project to link in? Again, I thought that Project References would make this unnecessary but it seems I don't really understand the Project References.
If at all possible could I get a very idiot proof, step by step procedure for setting up a Boost Test unit test project alongside a main project in VS2010?
Would I be better off going with the method laid out here (one project, different configurations to build tests or actual project exe):
http://blog.yastrebkov.com/2010/07/boost-test-setup-and-usage.html
Many thanks,
There is no magic behind setting up a Boost.Test project. Maybe because it's a regular C++ (executable) project in no way different from a "normal" application. This is what I do:
Create a new C++ project. I always choose Win32 Executable with precompiled headers. I have a naming convention, that all test projects using Boost.Test start with "tests.boost.testee_name..."
In "stdafx.h", add the include for <boost/unit_test.hpp> and define the BOOST_TEST_MODULE (I always choose the project name). Also, add all other includes for external components this project requires, e.g. other boost libraries, stl headers etc. This results in considerably faster compilation times.
The testee must be a library (dynamic or static). So "add reference" to all required dependencies. You can of course test header-only libraries, in that case do not add references.
Add source files to your test project, according to Boost.Test manual. The convention I enforce is one BOOST_FIXTURE_TEST_SUITE per file.
For convenience, I have a custom property sheet tailored for boost unit test, which I add to each boost test project. Among others it contains a post-build event, which runs the tests.
I have to add that, lately, I switched to MSTest with Visual Studio 2012 which allows a more comfortable way to manage the tests and test results. Nevertheless, for the most important parts of the software, I am still writing boost tests in order to ensure correctness with older toolsets and potentially other platforms.
Cheers,
Paul
I'm about to start a C++ project but I'm stuck at the basics.
I want to use the (linux) Code::Blocks IDE, and it's easy to create a normal project. However I want to do TDD using the UnitTest++ framework, and I don't know how to set everything up cleanly.
I've already asked a question about where to put the UnitTest::RunAllTests() command, and they told me the best place is the main() of a separate program.
How do I go about doing this in Code::Blocks? I think I need to create 2 projects:
The "real" project with its own main();
The unit testing project containing the tests and the main() with UnitTest::RunAllTests() inside.
Then somehow have the first project build and run the second during its build process. I don't know how to do that yet but I can find out on my own.
My questions are:
this is the right method?
do I have to create also a project for the UnitTest++ framework, in order to let other people build it on other platforms? Or is dropping the complied library in the project's path enough?
how can I organize the directories of these projects together? It'd be nice to put the tests related to each package in the same directory as that package, but is it ok to have multiple projects in the same directory tree?
I'll partly answer my own questions, as I've managed to get everything working.
Following the instructions on the official documentation page, I've put the UnitTest++ folder with the compiled library and all the source files in my project's path.
Then I created a test project for all the unit testing, with a main function containing the famous UnitTest::RunAllTests(). I put $exe_output as a post-build process here, in order to have the tests executed automatically every time I build this project.
I created the "real" project where my code to be tested will go. In the build settings I specified the test project as a dependency of the real project, so that every time I build the real one, it also builds the test project first.
With these settings I can work on my tests and on the real code, and I only have to build the real one to have the updated tests executed. Any failing test will also make the build fail.
Now two questions remain: "is this the best approach?" and "right now each project lives in a different directory. Is it wiser to leave it this way or should I put each test in the same folder as the real code to be tested?"
I am working on a program written in C++ using some c++0x features in Linux (Ubuntu). I have written a bunch of tests in Google Test. I am using g++ and plain makefiles which generate dependencies.
Now I want to work on a completely separate UI.
I have decided that Qt will be good, but found that it is kind of complicated to build. I see that the easiest thing is to use qmake.
I was wondering how I can build Qt into my application while keeping all the underlying classes independent of Qt. I understand how to do that by writing good code, but I want a good build system.
I don't want to switch to using Qt's unit testing framework because I only want to use Qt for the UI and I don't see the point of rewriting my tests.
Should I use qmake and modify it to produce my google test runner as well as the Qt app?
Should I keep my makefile and use qmake to build and link only the UI parts of the code which will depend on the .o files produced in the original makefile?
Should I do something else?
Finally, how would I do any of those above options?
CMake seems to work well with Qt (based on my experiences with my current project). There are a good set of macros to do all the standard Qt things, plus it integrates reasonably well with other tools. Your initial project may be a bit confusing to setup, but I'm sure there are numerous Qt examples available on the net.
You should not need to switch your testing framework to use CMake. I use the boost test framework, but as far as CMake is concerned any program which uses return codes will work just fine.
There is no reason to even partially use qmake if you use cmake.
Cmake is also cross-platform if that is a concern.
BTW, there is also no reason you have to stop using makefiles. Qt's qmake just calls a bunch of command-line tools which you can also do in make.
I'm just getting started with TDD and am curious as to what approaches others take to run their tests. For reference, I am using the google testing framework, but I believe the question is applicable to most other testing frameworks and to languages other than C/C++.
My general approach so far has been to do one of three things:
Write the majority of the application in a static library, then create two executables. One executable is the application itself, while the other is the test runner with all of the tests. Both link to the static library.
Embed the testing code directly into the application itself, and enable or disable the testing code using compiler flags. This is probably the best approach I've used so far, but clutters up the code a bit.
Embed the testing code directly into the application itself, and, given certain command-line switches either run the application itself or run the tests embedded in the application.
None of these solutions are particularly elegant...
How do you do it?
Your approach no. 1 is the way I've always done it in C/C++ and Java. Most of the application code is in the static library and I try to keep the amount of extra code needed for the application to a minimum.
The way I approach TDD in Python and other dynamic languages is slightly different in that I leave the source code for the application and tests lying around and a test runner finds the tests and runs them.
I tend to favour static libs over dlls so most of my C++ code ends up in static libs anyway and, as you've found, they're as easy to test as dlls.
For code that builds into an exe I either have a separate test project which simply includes the source files that are under test and that are usually built into the exe OR I build a new static lib that contains most of the exe and test that in the same way that I test all of my other static libs. I find that I usually take the 'most code in a library' approach with new projects and the 'pull the source files from the exe project into the test project' approach when I'm retro fitting tests to existing applications.
I don't like your options 2 and 3 at all. Managing the build configurations for 2 is probably harder than having a separate test project that simply pulls in the sources it needs and including all of the tests into the exe as you suggest in 3 is just wrong ;)
I use two approaches, for dlls I just link my unit tests with the dll, easy. For executables I include the source files that are being tested in both the executable project and the unit test project. This adds slightly to the build time but means I don't need to separate the executable in to a static lib and a main function.
I use boost.test for unit testing and cmake to generate my project files and I find this the easiest approach. Also I am slowly introducing unit-testing to a large legacy code base so I am trying to introduce the least amount of changes, in case I inconvenience other developers and discourage them from unit testing. I would worry that using a static library just for unit testing might be seen as an excuse not adopt it.
Having said this, I think the static library approach is a nice one especially if you are starting from scratch.
For C/C++ apps I try to have as much code as possible in one or more dlls, with the main application being the bare minimum to start-up and hand-off to the dll. Dlls are much easier to test because they can export as many entry points as I like for a test application to use.
I use a seperate test application that links to the Dll(s). I'm strongly in favour of keeping test code and "product" code in seperate modules.
I go with #1, some reasons are
It allows to check that each lib links correctly
You don't want extra code in the product
It's easier to debug individual small test programs
You may need multiple executables for some tests (like communication tests)
For C++ build and test, I like to use CMake which can run a selection of the target executables as tests and print a summary of the results.
Personnally, I use another approach that relies a bit on yours:
I keep the project-to-test intact. If it's an executable, it should stay an executable. You simply create a post build action in order to aggregate all obj files into a static library.
Then, you can create you test project, linking the test framework and your previously generated static library.
Here are some topics corresponding to your question:
Visual Studio C++: Unit test exe project with google test?
Linker error - linking two "application" type projects in order to use Google Test
I'm using a third-party test-runners with their framework and including testing in build script. Tests are outside of production code (external dll).