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 5 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I believe strongly in using unit-tests as part of building large multi-platform applications. We currently are planning on having our unit-tests within a separate project. This has the benefit of keeping our code base clean. I think, however, that this would separate the test code from the implementation of the unit. What do you think of this approach and are there any tools like JUnit for c++ applications?
There are many Test Unit frameforks for C++.
CppUnit is certainly not the one I would choose (at least in its stable version 1.x, as it lacks many tests, and requires a lot of redundant lines of codes).
So far, my preferred framework is CxxTest, and I plan on evaluating Fructose some day.
Any way, there are a few "papers" that evaluate C++ TU frameworks :
Exploring the C++ Unit Testing Framework Jungle, By Noel Llopis
an article in Overload Journal #78
That's a reasonable approach.
I've had very good results both with UnitTest++ and Boost.Test
I've looked at CppUnit, but to me, it felt more like a translation of the JUnit stuff than something aimed at C++.
Update: These days I prefer using Catch. I found it to be effective and simple to use.
You should separate your base code to a shared (dynamic) library and then write the major part of your unit tests for this library.
Two years ago (2008) I have been involved in large LSB Infrastructure project deployed by The Linux Foundation. One of the aims of this project was to write unit tests for 40.000 functions from the Linux core libraries. In the context of this project we have created the AZOV technology and the basic tool named API Sanity Autotest in order to automatically generate all the tests. You may try to use this tool to generate unit tests for your base library (ies).
I think your on the right path with unit testing and its a great plan to improve reliability of your product.
Though unit testing is not going to solve all your problems when converting your application to different platforms or even different operating systems. The reason for this, is the process unit testings goes through to uncover bugs in your application. It just simply throws as many inputs imaginable into your system and waits for a result on the other end. Its like getting a monkey to constantly pound at the keyboard and observing the results(Beta testers).
To take it to the next step, with good unit testing you need to focus on your internal design of your application. The best approach i found was to use a design pattern or design process called "contract programming" or "Design by contract". The other book that is very helpful for building reliability into your core design was.
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams.
In our development team, we looked very closely at what we consider to be a programmer error, developer error, design error and how we could use both unit testing and also building reliability into our software package through DBC and following the advice of debugging the development proccess.
I use UnitTest++. The tests are in a separate project but the actual tests are intertwined with the actual code. They exist in a folder under the section under test.
ie:
MyProject\src\ <- source of the actual app
MyProject\src\tests <- the source of the tests
If you have nested folders (and who doesn't) then they too will have their own \tests subdirectory.
Cppunit is a direct equivalent of Junit for C++ applications
http://cppunit.sourceforge.net/cppunit-wiki
Personally, I created the unit tests in a different project, and created a separate build configuration which built all the unit tests and dependent source code. In some cases I wanted to test private member functionss of a class so I made the Test class a friend class to the object to be tested, but hid the friend declarations when building in "non-test" configurations through preprocessor declarations.
I ended up doing these coding gymnastics as I was integrating tests into legacy code however. If you are starting out with the purpose of unit testing a better design may be simple.
You can create a unit test project for each library in your source tree in a subdirectory of that library. You end up with a test driver application for each library, which makes it easier to run a single suite of tests. By putting them in a subdirectory, it keeps your code base clean, but also keeps the tests close to the code.
Scripts can easily be written to run all of the test suites in your source tree and collect the results.
I've been using a customized version of the original CppUnit for years with great success, but there are other alternatives now. GoogleTest looks interesting.
Using tut http://tut-framework.sourceforge.net/
very simple, just header file only no macros. Can generate XML results
CxxTest is also worth a look for lightweight, easy to use cross platform JUnit/CppUnit/xUnit-like framework for C++. We find it very straightforward to add and develop tests
Aeryn is another C++ Testing Framework worth looking at
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to test my function and flows.
Lua scripts are a way for testing, Im able to load C Lib from lua and invoke the functions. The greatest advantage of using Lua is if you want to change calling scenerio, you just have to change your lua script file and execute it.
But I want to know that are there any better way to test a DLL code?
There is no such thing exist in the universe as "the best way".Citation needed
However, the generally accepted practice currently is to write automated unit tests. That is, you use a unit testing framework that allows you to express different scenarios of the consumption of the library code. You may think of tests as of a huge bunch of little programs that use the functions and classes in the library to verify their correctness, except that you don't actually write main functions, makefiles, printing and all the boring stuff is handled for you. Tests can pass or fail individually. Usually you can give names to them and organize into blocks. When test fails, a framework typically explain where and why, reducing the time and effort required for the debugging.
Unit tests are frequently built and ran automatically, e.g. by the IDE or a watch script after rebuilding your library and/or by a continuous integration system after a commit into a version control system.
Generally you write tests in the same language as your library (it's just simpler), but if your library is designed to interface with other languages you can of course use any or multiple of these languages as well.
There is an entire branch of programming methodology that is based on unit testing, called Test-driven development (TDD). In short, TDD instructs you to write a unit test first for a given scenario and only then the simplest library code that allows the test to pass.
Few examples of unit testing frameworks for C++ (no particular order):
Google Test
CppUnit
Boost.Test
Catch
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What are the best practices/guidelines for writing test suite for C++ projects?
This is a very broad question. For unit testing and Test Driven Development (TDD), there is some useful (if somewhat platidinous in parts) guidance on this from Microsoft - you can overlook the Visual Studio-specific advice, if it does not apply.
If you are looking for guidance on system or performance testing, I would clarify your question. There is a decent broader rationale in the docs for Boost.Test.
There are several unit testing best
practices to review before we close.
Firstly, TDD is an invaluable
practice. Of all the development
methodologies available, TDD is
probably the one that will most
radically improve development for many
years to come and the investment is
minimal. Any QA engineer will tell you
that developers can't write successful
software without corresponding tests.
With TDD, the practice is to write
those tests before even writing the
implementation and ideally, writing
the tests so that they can run as part
of an unattended build script. It
takes discipline to begin this habit,
but once it is established, coding
without the TDD approach feels like
driving without a seatbelt.
For the tests themselves there are
some additional principals that will
help with successful testing:
Avoid creating dependencies between
tests such that tests need to run in a
particular order. Each test should be
autonomous.
Use test initialization
code to verify that test cleanup
executed successfully and re-run the
cleanup before executing a test if it
did not run.
Write tests before
writing the any production code
implementation.
Create one test class
corresponding to each class within the
production code. This simplifies the
test organization and makes it easy to
choose where to places each test.
Use
Visual Studio to generate the initial
test project. This will significantly
reduce the number of steps needed when
manually setting up a test project and
associating it to the production
project.
Avoid creating other machine
dependent tests such as tests
dependent on a particular directory
path.
Create mock objects to test
interfaces. Mock objects are
implemented within a test project to
verify that the API matches the
required functionality.
Verify that
all tests run successfully before
moving on to creating a new test. That
way you ensure that you fix code
immediately upon breaking it.
Maximize
the number of tests that can be run
unattended. Make absolutely certain
that there is no reasonable unattended
testing solution before relying solely
on manual testing.
TDD is certainly one set of bests practices. When retrofitting tests, I aim for two things code coverage and boundary condition coverage. Basically you should pick inputs to functions such that A) All code paths are tested and better if all permutations of all code paths are tested(sometimes that can be a large number of cases and not really be necessary if path differences are superficially different) and B) That all boundary conditions(those are conditions that cause variation in code path selection) are tested if your code has an if x > 5 in it you test with x = 5, and x = 6 to get both sides of the boundary.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How do I get started doing unit testing in C++ ?
I have used Junit when coding in Java and found it very useful.
Is there something similar in C++ ? What do you recommend ?
Here are similar questions that you may want to look at:
Unit testing for C++ code - Tools and methodology
C++ unit testing framework
I recommend you check out Google's unit testing framework in addition to CppUnit.
I recently wrote a 5-part series of blog posts covering unit testing in C++ with boost. It gives step by step instructions for how to do this in Visual Studio.
Part 1: how to start making unit tests in C++ with Boost.Test.
Part 2: the assertion framework provided by Boost.Test in the context of a simple programming exercise that demonstrates test-driven development.
Part 3: continuing with test-driven development to complete the functionality of the PrimeFactors::Generate method.
Part 4: test-driven UI development.
Part 5: the facilities in Boost.Test for sharing common setup and teardown actions between tests and organizing tests into suites.
Check CppUnit, it's the jUnit port to C++.
UnitTest++, legend has it that UnitTest++ was written by the author of this comparison of unit testing frameworks.
Good round up here.
We use Boost.Test, and we are able to do good cross platform continuous integration.
Take a look at this page: http://gamesfromwithin.com/?p=29
It is the best comparison of the C++ frameworks. I personally prefer Boost.Test.
I haven't been happy with any C++ unit testing framework. Since C++ doesn't have reflection, it's hard to write convenient unit testing tools. CxxTest is about as good as I've found. I've used it on some projects, but usually I just write my own tests either without a framework or using a crude framework I wrote myself.
I just started using googletest (https://github.com/google/googletest/). Its simple to integrate and I haven't had any problems with it.
My personal favorite is TUT. The two main reasons are that 1) it doesn't force Java-isms on you but takes advantage of what C++ is, and 2) you have control over it, writing the executable (I have a template I used), the reporting etc (provides a stream based version by default).
To me it very much follows the philosophy of KISS, 2 headers, no macros, no parsers, just plain old C++ code with a tiny bit of skeleton code.
http://tut-framework.sourceforge.net/
I've just pushed my own framework, CATCH, out there. It's still under development but I believe it already surpasses most other frameworks.
Different people have different criteria but I've tried to cover most ground without too many trade-offs.
Take a look at my linked blog entry for a taster. My top five features are:
Header only
Auto registration of function and method based tests
Decomposes standard C++ expressions into LHS and RHS (so you don't need a whole family of assert macros).
Support for nested sections within a function based fixture
Name tests using natural language - function/ method names are generated
It also has Objective-C bindings.
Without knowing which platform/compiler you are targetting, I can only make a general recommendation. I've used this (CppTest) one quite successfully in the past. There's a simple framework called UnitTest++ that looks interesting.
Aeryn is another C++ Testing Framework worth looking at
Have a look at CUnitWin32. It includes an example.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm relatively new to J2ME and about to begin my first serious project. My experience in testing isn't too deep either. I'm looking for a unit test framework for J2ME.
So far I've seen J2MEUnit, but I don't now how well supported it is. I've seen JavaTest Harness but I don't know if it's not an overkill.
Please tell me what framework you suggest with respect to:
* Simplicity of implementing tests
* Supporting community and tools
* Compatibility with application certification processes
* Integration with IDEs (Eclipse, NetBeans)
* Other aspects you find important...
Thanks,
Asaf.
This is a blog entry of a spanish company who makes movile games. Compares many frameworks and the conclusion is (translated):
MoMEUnit Offer very useful
information about the tests. Is
easily ported and Ant compabile. A
disadvantage (or maybe not), its
that it needs that every test class
have an unique test method, using a
lot of inheritance.
JMEUnit. (Future merge of J2MEUnit
and JMUnit) JMUnit doesn't supports
Ant but the interface is similar to
MoMEUnit. J2MEUnit doesn't provide
very useful information with the
tests. Test creation in both
frameworks is somehow complex.
J2MEUnit does support Ant; thats
why the merge of both frameworks
will be very interesting(they have
been working on int for a year more
o less)
My experience: I've use J2ME Unit and setting up Test Fixtures is a pain due to the lack of "Reflection" in J2ME, but they are all build always the same way, so a template saves a lot of time.
I was planning to try out MoME Unit this week, just to check its simpler model
Some Test Unit Frameworks for J2ME:
JMUnit
MoME Unit
J2ME Unit
Sony-Ericsson Movil Java Unit
Take a glance at MockME as well.
www.mockme.org
From their site:
"MockME is Java ME mock objects for Java SE. MockME lets you write real unit tests without having to run them on the phone. You can even use dynamic mock object frameworks such as EasyMock that enables you to mock any object in Java ME! MockME integrates best-of-breed tools for unit testing including JUnit, EasyMock and DDSteps. By making Java ME API's mockable you can write unit tests for your Java ME application the way you really want to."
MicroEmulator + JUnit on J2SE
I started out with tools like JMUnit, but I recently switched over to standard JUnit + MicroEmulator on J2SE. This is similar to using MockME, but with MicroEmulator instead. I prefer MicroEmulator, because it has actual implementations of the components, and you can run an entire MIDlet on it. I've never used MockME myself though.
All my non-GUI unit tests are run by simply using MicroEmulator as a library. This has the advantage that all the JUnit tools work seamlessly, specifically Ant, Maven, most IDE's and Continuous Integration tools. As it runs on J2SE, you can also use features such as generics and JUnit annotations, which makes writing unit tests a little nicer.
Some components like the RecordStore require some setup before working. This is done with MIDletBridge.setMicroEmulator().
Using MicroEmulator also has the advantage that the implementation of some components can be customized, for example the RecordStore. I use an in-memory RecordStore, which is re-created before each test, so that I'm sure the tests run independently.
Real Devices
The approach described above won't run on any real devices. But, in my opinion, only GUI and acceptance tests need to be run on real devices. For this, tools like mVNC together with T-Plan Robot can be used on Symbian devices (thanks to this blog post). However, I could only get mVNC to work over Bluetooth, and it was very slow.
An alternative might be to use a service like The Forum Nokia Remote Device Access (RDA). I still need to investigate whether platforms like this are suitable for automated testing.
Hmm... I myself have not developed a mobile application but I think J2MEUnit is the better choice as its based on the original JUnit which has a big community and is supported by most IDEs so it should be guite easy to run at least those test which do not depend on the mobile hardware directly from your IDE.
More important might be that J2MEUnit integrates with ANT so you can run your test with every build.
A related document I found (after posting the question) is Testing Wireless Java Applications. It describes J2MEUnit near the document's end.
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 6 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm working on a large c++ system that is has been in development for a few years now. As part of an effort to improve the quality of the existing code we engaged on a large long-term refactoring project.
Do you know a good tool that can help me write unit tests in C++? Maybe something similar to Junit or Nunit?
Can anyone give some good advice on the methodology of writing unit tests for modules that were written without unit testing in mind?
Applying unit tests to legacy code was the very reason Working Effectively with Legacy Code was written. Michael Feathers is the author - as mentioned in other answers, he was involved in the creation of both CppUnit and CppUnitLite.
Google recently released their own library for unit testing C++ apps, called Google Test.
Project on Google Code
Check out an excellent comparison between several available suites. The author of that article later developed UnitTest++.
What I particularly like about it (apart from the fact that it handles exceptions etc. well) is that there is a very limited amount of 'administration' around the test cases and test fixtures definition.
Boost has a Testing library which contains support for unit testing. It might be worth checking out.
Noel Llopis of Games From Within is the author of Exploring the C++ Unit Testing Framework Jungle, a comprehensive (but now dated) evaluation of the various C++ Unit Testing frameworks, as well as a book on game programming.
He used CppUnitLite for quite a while, fixing various things, but eventually joined forces with another unit test library author, and produced UnitTest++. We use UnitTest++ here, and I like it a lot, so far. It has (to me) the exact right balance of power with a small footprint.
I've used homegrown solutions, CxxTest (which requires Perl), and boost::test. When I implemented unit testing here at my current job it pretty much came down to UnitTest++ vs boost::test.
I really like most boost libraries I have used, but IMHO, boost::test is a little too heavy-handed. I especially did not like that it requires you (AFAIK) to implement the main program of the test harness using a boost::test macro. I know that it is not "pure" TDD, but sometimes we need a way to run tests from withing a GUI application, for example when a special test flag is passed in on the command line, and boost::test cannot support this type of scenario.
UnitTest++ was the simplest test framework to set up and use that I have encountered in my (limited) experience.
I'm using the excellent Boost.Test library in conjunction with a much less known but oh-so-awesome Turtle library : a mock object library based on boost.
As a code example speaks better than words, imagine you would like to test a calculator object which works on a view interface (that is Turtle's introductory example) :
// declares a 'mock_view' class implementing 'view'
MOCK_BASE_CLASS( mock_view, view )
{
// implements the 'display' method from 'view' (taking 1 argument)
MOCK_METHOD( display, 1 )
};
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v;
calculator c( v );
// expects the 'display' method to be called once with a parameter value equal to 0
MOCK_EXPECT( v, display ).once().with( 0 );
c.add( 0, 0 );
}
See how easy and verbose it is do declare expectation on the mock object ? Obviously, test is failed if expectations are not met.
I've just pushed my own framework, CATCH, out there. It's still under development but I believe it already surpasses most other frameworks.
Different people have different criteria but I've tried to cover most ground without too many trade-offs.
Take a look at my linked blog entry for a taster. My top five features are:
Header only
Auto registration of function and method based tests
Decomposes standard C++ expressions into LHS and RHS (so you don't need a whole family of assert macros).
Support for nested sections within a function based fixture
Name tests using natural language - function/ method names are generated
It also has Objective-C bindings.
CxxTest is a light, easy to use and cross platform JUnit/CppUnit/xUnit-like framework for C++.
CppUnit is the way. See link below:
http://cppunit.sourceforge.net/cppunit-wiki
http://en.wikipedia.org/wiki/CppUnit
UnitTest++, small & simple.
I am currently looking for a unit test and mock framework that can be used at our company for a long lived code-base. As you know the list of unit testing frameworks for c++ is long so I applied some filters to reduce it to a hand-full that can be looked in more closely. The first filter criterion was that it must be for free. The second criterion was project activity. I also looked for mocking frameworks because you need one if you want to write unit-tests.
I came up with the following list (approximately) sorted by activity, highest activity at the top:
GoogleTest / GoogleMock: Many contributers and used by Google itself. This will probably be here for some time and receive updates. For my private code-base I will switch to this combination in hopes to jump on the fastest train.
BoostTest + Turtle: Not updated that often, but the testing framework is a part of boost so it should be maintained. Turtle on the other hand is maintained by mainly one guy, but it has resent activity so it is not dead.
I made almost all my testing experience with this combination because we already used the boost library at my previous job and I currently use it for my private code.
CppUTest: Provides testing and mocking. This project has been active from 2008 to 2015 and has quite a lot recent activity. This find was a little suprise because a lot of projects with significantly less activity come up more often when searching on the web (like CppUnit which had its last update in 2013). I have not looked deeper into this so I can't say anything about the details.
Edit (16.12.2015): I recently tried this out and found this framework to be a little clumsy and "C-stylish", especially when using the mock classes. Also it seemed to have a smaller variety of assertions then other frameworks. I think its main strength is that it can be used with pure C projects.
QTest: The test library that ships with the Qt framework. Maintanance should be guaranteed for some time, but I use it rather as a supporting library, because the test-registration is IMO more clumsy then in other frameworks. As far as I understand it, it forces you to have one test-exe per test-fixture. But the test helper functions can be of good use when testing Qt-Gui code. It has no mocks.
Catch: It has recent activity but is mainly developed by one guy. The nice thing about this framework is the alternative fixture approach that lets you write reusable fixture code in the test itself. It also lets you set test names as strings which is nice when you tend to write whole sentences as test names. I whish this style would be ripped of and put into googleTest ;-)
Mock Frameworks
The number of mock frameworks is much smaller then the number of test frameworks but here are the ones that I found to have recent activity.
Hippomock: Active from 2008 unitl now but only with low intensity.
FakeIt: Active from 2013 unitl now but more or less developed by one guy.
Conclusion
If your code-base is in for the long run, choose between between BoostTest + Turtle and GoogleTest + GoogleMock. I think those two will have long term maintenance. If you only have a short lived code-base you could try out Catch which has a nice syntax. Then you would need to additionally choose a mocking framework. If you work with Visual Studio you can download test-runner adaptors for BoostTest and GoogleTest, that will allow you to run the tests with the test runner GUI that is integrated into VS.
See also the answers to the closely related question "choosing a c++ unit testing tool/framework", here
There also is TUT, Template-Unit-Test, a template-based framework. It's syntax is awkward (some called it template-abusing), but its main advantage is that is it all contained in a single header file.
You'll find an example of unit-test written with TUT here.
I've tried CPPunit and it's not very user friendly.
The only alternative I know is using C++.NET to wrap your C++ classes and writing unit tests with one of .NET unit testing frameworks (NUnit, MBUnit etc.)
CppUTest is an excellent, light-weight framework for C and C++ unit-testing.
Michael Feathers of ObjectMentor was instrumental in the development of both CppUnit and CppUnitLite.
He now recommends CppUnitLite
Have a look at CUnitWin32. It's written for MS Visual C. It includes an example.
Have a look at cfix (http://www.cfix-testing.org), it's specialized for Windows C/C++ development and supports both user mode and kernel mode unit testing.
If you are on Visual Studio 2008 SP1, I would highly recommend using MSTest for writing the unit tests. I then use Google mock for writing the mocks. The integration with the IDE is ideal and allows and doesn't carry the overhead of CPPunit in terms of editing three places for the addition of one test.
I think VisualAssert is doing a great job in VS integration. It lets you run and debug the tests from VS and you don't need to create an executable in order to run the tests.
Check out fructose: http://sourceforge.net/projects/fructose/
It's a very simple framework, containing only header files and thus easy portable.
I'm using MS Test with Typemock Isolator++. Give it a try!