If the control software in a car bucks, customers are at best only annoyed because, for example, a function is not available. In moving traffic, however, software errors can quickly become a danger to life and limb, both in cars and when moving heavy construction and agricultural machinery. In view of increasingly complex control software, it is becoming more and more difficult to maintain high code quality, especially for projects in the C programming language. With its own test environment, EDAG offers a solution that saves time and resources.
The more functions are mapped in software, the more assistants help the users of vehicles and machines during operation, the more complex the underlying control software becomes. This is particularly critical for C projects, i.e. embedded systems in the C programming language, which are procedural and not object-oriented. They are much more difficult to test than projects in C++, for example, which can be structured and modularized much better. In fact, around 80 percent of the control units in cars, commercial vehicles, construction and agricultural machinery are programmed in C.
Unit testing is an important concept for ensuring software quality. This involves isolating functions and components of the code and subjecting each to its own tests. This means that not the entire code, but only individual sections ("units") are tested for errors. The parameters of the test strategy in conjunction with the test coverage are used to measure the quality of the software. Developers are under increasing pressure to make use of such tools. This is due not only to the growing complexity of software, but also to increasing pressure from customers.
There are a handful of different frameworks for creating unit tests, as well as some mock frameworks for integration into C projects. However, they have one major disadvantage: every test has to be set up manually and the setup has to be done manually. This requires an enormous amount of resources - around 20 to 25 percent of the developer's time is taken up by testing the code alone, despite such tool support. In view of the shortage of skilled workers, this poses almost insurmountable problems for development teams: Neither cutting back on code quality is a viable option, nor is extending project runtimes. There is even more trouble in store for the future. As with ADS and ADAS, for example, which are part of homologation, the reliability and accuracy of the control software could also be regulated in view of the existing challenges.
Efficient overall solution
EDAG has addressed this dilemma and developed a comprehensive test environment that is both resource-saving and user-friendly, thus simplifying the introduction of unit testing considerably. The essential components are
- A self-developed test environment generator,
- a self-developed generator for mock objects and
- Accompanying implementation and training concepts.
The overall solution developed by EDAG is primarily intended for use at the application level of a C project. However, this test environment also offers great advantages for unit testing for other projects with many dependencies thanks to the automatic "mocking" and breaking of such a structure.
One of the development goals was to keep the operation and integration of the test environment lean and simple. This means that it can be quickly learned and used by the development team. Due to the accompanying support with the test strategy and introductory training, use by the entire development team is the rule rather than the exception.
Automation in unit testing
The test environment can be integrated into a CI/CD pipeline (Continuous Integration / Continuous Deployment) in order to carry out automated tests and generate test reports. Various templates are already integrated and only need to be adapted for the desired system, for example when using Jenkins servers. 
During the automated test of the entire software, all existing code sections are tested and the newly added functions are also tested. This prevents "new code" from causing errors in the existing code. This is because an "old" test would then throw an error. Ideally, all tests are run without errors, then the code can be transferred to the main repository.
An important point is the quantifiability of software quality. The parameters of the test strategy in conjunction with the test coverage serve as measurement values for the quality of a software. It is also possible to evaluate how often software was uploaded that contained errors, how many errors were contained in the first version and similar.
This can be used to communicate openly with customers about quality efforts and results. It contributes to a better basis of trust if, for example, you can demonstrate to them: "New software versions are created five times a week, of which only once is code that does not pass without errors, that was fixed in one day, and now we have code that is 95% tested according to this strategy and is completely error-free in this area."
Positive customer reactions
The EDAG test environment is already in practical use, three project teams are already using the in-house development for their embedded systems and a fourth is currently preparing it. In one large company, the DevOps department has taken over this project and is introducing it in all relevant projects throughout the group. Users were surprised by the possibility of even being able to test C projects, whose roots go back to the 1990s.
When designing the EDAG solution, care was taken to ensure that the unit testing can in principle be adapted to any C project, so that the widest possible applicability is guaranteed in practice. However, if it becomes too difficult, parts of the code can be excluded from testing.
The high degree of automation and the detailed documentation of the test environment were also positively received. In addition, a number of suggestions from users have already been incorporated into the solution, which is being continuously developed. As a result, the utility value has been further increased.
Based on this practical experience, savings of 75 to 90 percent of the manual testing effort can be calculated. For an experienced programmer in a conventional test environment, for example, it takes 12 minutes to set up a test and 10 minutes to write a test, and even longer without the appropriate frameworks. In the EDAG environment, on the other hand, the same tasks are completed in 2 or 3 minutes.
If you extrapolate the time advantage to an entire project, hundreds of hours can be saved very quickly. Depending on the size of the development team, this is equivalent to the work of a full-time developer.
Do you also want to make your embedded systems more reliable and secure? Are you interested in efficient unit testing for your C projects? Then talk to Oliver Wolf from the Embedded Software team at EDAG, who developed the automated test environment. Or download our white paper "Higher quality for C projects with less effort" here, which provides further technical details on unit testing with the EDAG test environment. 
