Pioneer Corporation Mobile Entertainment Business Group, Kawagoe Plant

In recent embedded device development, improving embedded software design quality has become a common challenge. As most product functions have come to be implemented through software, insufficient testing behind the scenes has led to numerous issues in the market. In development environments, debugging and testing processes are still frequently left to individual developers, and there are still many cases where development progresses relying on each developer's personal skill within short development timeframes.

In the field of automotive control software, unit testing has long been implemented as a mandatory requirement in many cases. In other product domains, however, awareness of unit testing itself remains low, and it is largely omitted from the development process. Currently, it rarely goes beyond software developers performing function testing as part of debugging.

However, as the increasing scale of software implementation requires larger development teams, it has become necessary to evaluate and manage the quality of developed software and functions across the entire project using common metrics.

Even in fields other than automotive, an increasing number of projects are adopting "unit testing" for software quality management and improvement.

Originally, functions are coded based on detailed function design specifications. Therefore, one of the main purposes of unit testing is to conduct function input/output testing to verify whether the original function specifications match the implementation code. This confirms that there are no implementation errors and evaluates whether the function operates correctly as defined in the specifications. To achieve this, input data is prepared based on the design specification document, and tests are conducted treating the function as a black box to verify that it produces outputs according to specification. Test cases are designed so that the expected input data covers the range of values defined in the specifications, evaluating whether numerical operations and conditional logic are executed correctly.

In addition, evaluating function quality includes assessing robustness against input conditions not defined in the specification document. Apart from the functional aspects mentioned above, it is also necessary to evaluate whether protective code against division by zero or NULL pointer access is properly implemented within the coded logic to handle anomalies correctly.
Furthermore, it is essential to check that no unnecessary or dead code remains hidden within the function, which is verified by applying code coverage to comprehensively execute the implemented code.

When it comes to unit testing, discussions often focus on "coverage" metrics like C0, C1, C2, and MC/DC. However, satisfying even the most stringent C2 coverage does not guarantee that the software is free of errors. As mentioned earlier, unit testing is the process of evaluating consistency with function specifications and verifying that there are no errors in the implemented code. While coverage testing can demonstrate that no errors exist within the scope of the written code, it cannot verify whether all features defined in the specifications have been fully implemented without omission. To determine that, evaluations must clearly be based on the specifications.

There are three key points to verify in unit testing:

1. Whether the designed features are implemented
2. Whether there is any dead code (unintended code or branches) caused by implementation errors
3. Whether there are any code-level defects (issues in variables, branch conditions, or calculation processes)

Unit testing requires a test plan tailored to these verification points.

In this section, with the cooperation of the Mechanism Development Department, Technology Executive Division, Kawagoe Plant, Mobile Entertainment Business Group, Pioneer Corporation (hereinafter "Pioneer"), we introduce a user case study of CoverageMaster winAMS.
CoverageMaster winAMS is applied in the development of DVD drives used in Pioneer's car navigation products. These DVD drives are also supplied externally to third parties and serve as core device components, demanding high reliability. Furthermore, as the market leader in commercial car navigation, Pioneer maintains a strong corporate commitment to leading the industry in design quality as well.
For this reason, this development department has integrated unit testing directly into its development process as part of its software quality improvement initiatives.

Most of the software developed here is related to mechanism control for DVD drives. For this reason, both mechanical and software engineers belong to the same department to facilitate close coordination between hardware and software development.
The specifications of the DVD drives being developed must be modified to meet the requirements of target products. This is accomplished through close collaboration between mechanical and software design; however, because altering mechanical components is difficult, tuning is frequently applied through software to accommodate the finalized hardware.
Since the core functionality of DVD drives remains fundamentally identical, software development is carried out by making requirement-driven modifications to a unified source code base originally created as the base software.

In this department, software developers handle the process from design → coding → static analysis/code review → unit testing → integration testing (within a single feature scope) once specifications are finalized. Subsequent integration system testing is conducted by all team members, while system testing for the final product is performed by a dedicated team.
In past development projects, although rules such as conducting path checks were established for the unit testing phase, execution was largely left to individual developers, and verification was primarily visual checking. As a result, evaluating all software against a uniform standard proved difficult.
A review of past software verification results revealed that human errors at the coding level were a primary cause of defects. Initiatives toward unit testing were undertaken specifically to detect these errors prior to integration testing.

The reasons and objectives for adopting "CoverageMaster winAMS" as a unit testing tool are summarized as follows:

· Software evaluation standards, which previously varied by developer, can be standardized using automatically generated coverage results.
· By using an MCU simulator (ISS), the most reliable target code verification can be performed.
· High operational efficiency, with no need for code additions, modifications, or recompilation for testing.
· Execution time of instruction code can be measured, which can be utilized for mechanism control tuning.
· An automated testing system can be constructed.

The tool concept of "CoverageMaster winAMS"—enabling MCU target code verification—was well-suited for testing mechanism control software close to hardware. In this article, we would like to particularly introduce the automated testing system among these features.

Unit test data for source code developed by each engineer is created by the engineers themselves. To minimize variations in testing quality among developers, test guidelines are established covering test perspectives, test data creation, and stub function creation.
After completing specification verification and source code review, each developer executes unit tests on their developed code. Once they confirm that testing complies with the guidelines, they register the developed source code and test data into an automated testing system set up on a dedicated PC.
Every two hours, the automated testing system automatically rebuilds the registered source code, launches "CoverageMaster winAMS", executes the unit tests, and outputs the results to a designated folder.
Even when multiple developers modify the same source code for mechanism control tuning, the impact of those changes across the development project can be verified every two hours. Furthermore, once test data is created, developers are freed from daily manual testing tasks, contributing significantly to development efficiency.
As described above, Pioneer ensures software quality in daily development work through its proprietary automated unit testing system. Compared to previous visual inspection methods, automation has dramatically accelerated and improved the quality verification process, yielding substantial results.

Finally, GAIO introduces unit testing automation using "CoverageMaster winAMS."

While the term "automated system" may sound complex, in reality, it can be easily constructed using batch files executed in the Windows command prompt.
The workflow first invokes a Makefile to rebuild the source code collected by each developer in a designated folder on the server. Subsequently, the "CoverageMaster winAMS" test project is launched from the command line to execute tests sequentially.
This simple process is all it takes to automate unit testing.

In Conclusion
As demonstrated, automating unit testing is extremely effective in multi-developer projects for regularly tracking how a change made by one developer impacts other parts of the project.

We encourage you to consider adopting an automated unit testing system for your own development as well.