I am a student developing a microcontroller application that uses the Azure RTOS ThreadX, and I never used tests and want to start doing unit testing, integration testing, and automatic tests. I found out the Ceedling and Google Test frameworks, but I would like to know what the community and the ThreadX team uses or recommends to proceed with the tests.
My programming language is C, and I'm using a Cortex M0+.
ThreadX has a custom test suite, specifically written to test and certify the RTOS and middleware.
For your application code on top of the RTOS you can use the suites you mentioned.
I would recommend that in addition to unit-testing you use a static analysis tool or two, to identify other types of problems. During unit-testing and system testing it is also useful to measure code and branch coverage as well as use a profiler to verify performance.
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 am interested in the following scenario specifically. Suppose you have team that writes production code and a team that writes automatic tests. The team that writes automatic tests has a dedicated framework intended to write the automatic tests. Should the testing team write unit tests for their framework although the framework is not used in production?
I've been in that situation and what I did is use the test suite for the production code also as a test suite for the testing framework. Presumably, all the features of the framework were actually used, so if tests failed without a change in production code, then there must be a problem in the testing framework.
It worked OK-ish - running those tests took much longer than having a dedicated test-testsuite would have, and sometimes I wouldn't run all of them and have a problem turn up on the production build server. Diagnosing such problems took much longer than it would have with a test-testsuite.
All in all, I never felt comfortable with it and would really recommend having dedicated tests for the test framework as well. From the point of view of the test-writing team, the testing framework is production code. And if the testing framework ever gets used by anyone else, whose test suites you don't have access to...
Hell yes!
TDD gives you an edge in developing, it's not just to please the customer. It allows you to write testable, reusable and modular code. I would unit test everything that has to work, expecially if you expect to change it often (refactor to add new features).
The testing team should do whatever that can increase their trust in the results delivered by their framework.
This includes testing, code reviews, quality standards, ...
Yes, if only to test that the framework generates sufficient test coverage.
This question reminds me of a story: Once upon a time there was a company. This company believes in automatic tests. This belief is so strong it leads to creating a group whose sole purpose is writing these automatic tests. All the most ardent believers are allowed to join this group. There was much rejoicing!
Then one day, it's discovered that this automatic testing group, despite its mission, doesn't use automatic tests for its own work. Stones are cast, yada yada.
I'm just saying... I would think that any testing framework would have pretty solid test coverage.
For those of us who like to learn by reading good code, what are some of the projects you've seen which provide a great example of a medium to large suite of unit tests in action?
This isn't a question about what your favourite unit testing framework is, but it could be helpful to add which unit testing and/or mocking frameworks are used by the projects you mention.
Any platform will do, but I'm mainly interested in projects which use an xUnit-style unit testing framework in .NET.
Apache CXF has a mind-numbingly large array of unit tests. They are written to Junit, and include the JUnit-Spring mechanisms as well as one of the mock libraries. They include launching processes and many other mechanisms you might need some day.
For example, ReportLab uses Python's unittest module (also known as PyUnit) and has lots unit test that you might want to take a look at.
I'm also using unittest myself. It is very similar to Java's jUnit framework and thus very handy for writing tests in no time.
The Service Factory has about 780 unit tests, including some that test code meant to run inside of Visual Studio. It has some very good examples of mocking such code.
The Enterprise Library has even more.
NunitLite has a unit tests suite but I'm not sure it qualifies as a medium-sized project. I seem to remember NUnit also has unit tests, but its site currently is unavailable.
I've been reading a lot about Unit tests and Test Driven developemnt.
Recently, I also read java unit test code.
I however, prefer to develop in Qt. So I googled up "unit testing in c++" and found a host of information about various unit testing frameworks available for C++.
However, I could not find a reliable comparison of the the various frameworks.
So I look to the SO community to guide me through the selection of what may the "best" unit testing framework for c++.
Also, if anybody had specific comments regarding TDD in Qt (especially using Qt-Creator), then they are more than welcome.
Usually use Boost, but if you are using Qt, their QtTestLib might be the better choice.
I would recommend doctest (created by me) - it's the lightest on compile times from all the popular testing frameworks. It is also a direct competitor to Catch which is currently the most used framework - checkout the differences in the FAQ
This seems too be the same question as:
Unit testing in C++ which is actually c++ despite the URL title.
From there, they link to two more SO questions which should help:
Unit testing for C++ code - Tools and methodology
C++ unit testing framework
There is a table comparing all (?) the C++ unit test frameworks available from wikipedia.
There also is an old comparison of C++ unit test frameworks available. I do not think it has not been updated so I mention it as a complement as it's more argumented than the table. It covers, CppUnit, CppUnitLite, Boost.Test, NanoCppUnit, Unit++, CxxTest, especially it does not cover Google C++ framework.
The "xUnit" family of testing frameworks is usually pretty solid (jUnit, NUnit, etc.). I haven't used it myself, but there is a port of jUnit for C++:
http://sourceforge.net/projects/cppunit
Boost is usually a good choice, and it contains a testing framework, the Boost Test Library. I have used it for small test cases and it did what I expected, but I haven't used it extensively like in TTD.
If you want to get off the ground quickly without figuring out how to build a library, there is a single header file include solution, which supports fixtures (setup and teardown), the usual TEST() {} with CHECK_TRUE, etc.
It also has memory leak detection and performance testing capabilities.
https://gitlab.com/cppocl/unit_test_framework
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.