The practice of continuous integration (CI) is well established within traditional C development environments and is at the core of agile workflows. Model-Based Design processes are able to extend the base level of CI testing through the use of simulation to validate functional behavior. While this is possible in traditional environments it requires the development of specific test harnesses which the MBD environment provides for “free”
Continuous Integration: Background
There are 5 best practices for CI systems
- All source objects must exist in version control: Source objects are used to create derived objects such as C code or test results. The derived objects do not need to be kept in the repository.
- All operations on the objects must be automated: Operations include code generation, running test, collecting code metrics.
- Any commitment to the repository should trigger a build and test operation: The “level” of test can be set for each check-in. If the impact of the check-in is localized then a subset of the tests should be run.
- Results from build and test are easy to interpret: Every build and test operation should generate a report. Results in that report should be easy to interpret and, in the case of errors, easy to trace back to the root cause of the error (e.g. which file resulted in the failure.)
- Minimize build and test execution time: To the extent possible the execution time of the build and test operations should be minimized.
The continuous integration workflow
The continuous integration workflow has two primary paths, an event, and temporal based triggers. With the temporally-based trigger, the testing environment is run at predetermined intervals, generally nightly and weekly test runs. With the event-based triggers, the testing environment is “triggered” by the check-in of a model or related data objects.
To improve the speed of test execution the concept of test “levels” is introduced. At each level, the pass/fail criteria are assessed and if passed the next level for that model can be run; failure results halts further testing.
|Level 1||Smoke tests to ensure that the model updates and passes basic modeling guideline checks||Check-in, Nightly, Weekly|
|Level 2||Functional testing against requirements||Checkin, Weekly|
|Level 3||Coverage and functional testing||Weekly|
The key consideration is the set up of testing infrastructure “patterns” that enable simple integration with the CI system down the road. These testing patterns will be covered in a future post.