For one of my projects i am using nucleus RTOS as a operating system. Now i want to unit test the code written in embedded C++. Please let me know how this can be done.
I have explored so much from internet got nothing.
Not being familiar with the nucleus RTOS, I did some looking on the Mentor Graphics web site. It looks like a variety of linux based kernels are available for the different hardware. Is the GNU compiler being used? Regardless of the compiler, it may be a good idea to review the symbolic links by running: ls -l `which lynx` | more within /usr/bin for your own peace of mind.
After downloading and extracting the cppunit files, the text file which helps understand how to construct the cppunit libraries for a system is named INSTALL. It is located in the base directory of the cppunit extraction (e.g. cppunit-1.12.1). Within INSTALL are the procedural steps to construct cppunit with the supplied script (more below) and the make command.
Inside the cppunit 1.12.1 source code set, is the shell script named configure. When that runs, the two most important environment variables to set to the values necessary for the OS and compiler used in the development environment are: CC and CXX. They can be set on the command line that executes the script. The configure script sets the building blocks (if you will) for the next step that executes make to construct all of the cppunit binaries and libraries.
An example execution command for OS X Mavericks inside the cppunit-1.12.1 directory:
./configure CC=/usr/bin/clang CXX=/usr/bin/clang++
You may need to add sudo in front of ./configure on the command line. Later in the building command procedure, sudo has a much higher chance of being used (e.g. sudo make install). As an experiment, I reviewed the Makefile contents without setting CC and CXX. The GNU compilers for C and C++ have been set, when I have requirements to use the C++11 standard. The Mac OS X system has older GNU compilers which are not C++11 compliant. Only the LLVM clang++ is C++11 compliant on the Mavericks command line utilities. So please be thorough determining the correct CC and CXX values when executing the configure script. The configure script can be run as many times as needed before proceeding to create the cppunit libraries with make. At least, I tried this about four times to see what would happen. On the 2.53 GHz i5, the script takes about two minutes to complete.
After observing all of the binaries and library files being created, they should then be successfully copied to the directories you will use to compile and link in for the test suite. For example, when creating the NetBeans 7.4 IDE, using cppunit, I have added the working directory (.) to the Test Files | C++ Compiler project settings. I have also added the /usr/local/lib library directory path and the libcppunit.a static library to the Test Files | Linker settings (e.g. full path to the static library file: /usr/local/lib/libcppunit.a).
After doing this, building the test case suite and subsequently running all tests successfully execute within the NetBeans IDE. The NetBeans IDE is solid enough to have its own Test Unit GUI in a dedicated Test Results tab.
Not knowing which IDE is being used, it may be necessary to create the TestRunner file for your class under test. The TestRunner file contains the main function for your test execution. A typical name for this file is ClassNameTestRunner.cpp. The NetBeans tool does this for me when adding a new CppUnit Test to the Test Files project area. It may also be necessary to create the TestClassName cpp and h files manually as well. Your mileage may vary.
I hope this helps. There are fundamental macros to use within the test cases that will display and track results as needed. It is even possible to show the failure message with the expected, result, and delta between them (e.g. CPPUNIT_ASSERT_DOUBLES_EQUAL_MESSAGE(message, expected, result, delta).
Log in to post a comment.