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.
Related
I have been tasked with finding the best way to do integrated unit testing. We have a very large Java EE 5 application (desktop). Right now we use a tool called QF-TEST which is pretty cumbersome for large tests and can be difficult to use (easy to break) with any code changes.
We now want to do something that is more standard and gives the developers more control.
I have read a few posts here:
Unit testing in Java EE environment
Automated Testing - kind of cool, although for .Net
Best practice approach for automated testing
easiest Automated testing tool in Java
From the general information I have read JUnit/JUnitEE is probably the best (by best I mean quickest to learn and possibly the JAVA standard).
Is JUnit the way to go for large Java EE applications? What are some other options that others find better (if there are any)?
Thanks!
That's a very broad question. It's the topic of many books. Start with JUnit, start reading about test-driven design/development (TDD), and build from there. Ask more specific questions as you come across them. You could start with "Test Infected", a rather old, yet still applicable article on the JUnit site.
I think for java I would go with either with junit or testNG frameworks, If you have persistence/data base involved in the application, I would add dbUnit to the mix.
If you have build scripts like maven or ant or gradle, I would also suggest you look into Jenkins and similar tools to automate builds.
I am suggesting maven because it has life cycle events for testing, You can add targets with ant, I have not used gradle but if I was given choice, I would choose gradle
JUnit is not the way to go for large Java EE applications, it is a bare minimum.
But since you already have an application writing jUnit tests will not help you, because jUnit is not a testing tool. jUnit is used for TDD and refactoring safety, writing jUnit tests as an afterthought simply does not work.
That said you should learn jUnit4 as soon as possible (it can be done in 60 seconds)
and than learn about TDD (it can be done in 2-3 hours)
and use jUnit for every future code change you make to your application.
As for code you already have, what you need is 'code analyzers'.
That means tools that will check your source code for violated coding standards, code duplication, do code coverage, dependency analysis and complexity monitoring.
(All of these and more exist as eclipse plugins)
You will probably also need some 'java gui testing' framework (to replace QF-TEST)
There are a lot of open source alternatives there, search the web.
I'm thinking of designing my own Test library (framework) ->in c++
I am wondering if some of you have already designed there own (and what good advices, documentation they could offer me), decided to not do that (and why), What critics (and argue) you have against differents existing testing frameworks.
I want to no more about testing framework design.
In fact I have some pretty differents things to test :
simple unit test
MVC and signal slot
data, (escpecially for audio and DSP)
performance
compatibility
"So much things ... and so few time "
No really I need to test a lot of different things.
So I checkout how is designed XUnit, and the Addison and W XUnit related book, also the Advanced Unit Testing related article on code project....
And different articles, discuss this with coworkers ...
And at the end, I want to design my own.
Why :
specific needs,
like the do it yourself way (and learn why it's done this way in existing frameworks and that I'm not a genious ... ^^)
Thank you all.
I remember having read some discussions about Cppunit 2 design on the sourceforge wiki. I'd start from here. Also, Noel Llopis explored the C++ unit-testing framework jungle.
But, you're saying you want to re-create another framework and you only have few time left. I'd suggest picking one framework fitting your need for the unit tests, see if it can be used fore your MVC and data testing. Moreover unit testing framework are not designed to run performance tests. I'd recommend following the Unix philosophy here: simple little tools that do one thing and do it well.
Learn at least one existing framwork before you implement your own. My experience is that the framework is not the problem. Learning how to write good unit tests is the hard part.
I have used several framworks through the years including CxxTest, CppUnitLite and UnitTest++. But my recommendation is Google Test together with Google Mock (Google Mock comes with a copy of Google Test bundled).
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.
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
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!