TDD Design Process

Write a  new test. Known‐to‐ Unknown Defect Implementation Detail Requirement

Figure 6.1: Origins of a new test

6.1.2 TDD Design Process

A frequently used architectural pattern for software engineering is the Model-View- Controller pattern (MVC) [197]. Please note that the terms “Model” and “Con- troller” here have a different meaning than in control theory. To distinguish the different meanings, the first letter is a capital when we speak of the pattern meaning, and a lower-case letter otherwise.1 _{The Model contains the core of the application}

and represents its domain-specific information. The View is the output interface to the user and displays the Model’s data. Its counterpart is the Controller, which implements the input interface. With the Controller, the user is able to access the model’s functions. In terms of embedded systems, the Controller and the View are typically realised as one or more different electronic control units and physically con- nected to the electronic control unit which implements the model, see Figure 6.2(a). Furthermore the Controller and the View do not only interface to the user, but also with the system’s environment through sensors and actuators. TDD supports the development process of this pattern by replacing these components with mock inter- faces, i.e. test stimuli for the input variables and assertions for the output values.

1_{Thus model and controller are terms of control theory, Model and Controller terms of the MVC} pattern.

An example for such a system is the Collision Prevention System introduced in this thesis, which uses the Instrument Cluster for the View and the brake pedal as well as other input devices for the Controller. Both are connected via a CAN bus to the Radar Control Unit which realises the Model.

The main disadvantage of this description is that the plant is not explicitly included in one of the three MVC components. Its potential position would be in-between the Controller and the View, thus connecting sensors and actuators. Therefore the MVC pattern is modified to characterise an embedded control system in the context of control theory. Here, the Model represents the plant and the Controller represents the implemented software including, for example, a feedback controller. The View comprises the input and output interfaces only to the user, but not to the sensors and actuators as they are part of internal interface between Controller and Model. The block diagram of the modified MVC pattern is shown in Figure 6.2(b).

Controller

View Model

Users Sensors

Displays Actuators

(a) Classic structure

Controller

View Model

Users Displays

(b) Modified structure Figure 6.2: The Model-View-Controller pattern

The advantage of the modified pattern is that it helps us to better understand the role of TDD as a software process. The TDD approach can be divided into two simple elements: the Test and the Test Objective. While a test objective realises a part of the system’s requirements, a test drives its design and verifies its realisation. Therefore both elements constitute an executable form of the system’s requirements. Compared to MVC, we identify the Controller as the test objective and the Model as well as the View as its design guide and its verification. The Model can be described by the real plant, i.e. by system tests in a real environment, but also by plant models.

In fact, a single unit test usually specifies only a part of the Model or even only a single aspect of it. The same applies to the View. The major difference between the Model and the View is that the Model is typically tested in a closed loop together with the Controller due to the use of plant models. Instead, the View is tested as an open loop, i.e. the user’s input is specified independently of the system’s response. An example has been given with the development of the component Driver Assessment in Section 3.4.2.

Furthermore, the iterative cycles of TDD allow to analyse and to react to unknown or incompletely known characteristics of the plant. When we start with an unknown plant, a new test case describes an input stimulus of the plant, while the outputs are observed by the developer. In Figure 6.3, a test case is represented by a circle within the Model or the View. The geometrical form of a circle was chosen, because the plant’s characteristics are never fully known. Then a part of the Controller is added to make the failing test pass. As the Controller can be fully implemented in terms of its requirements, its rectangle is filled with squares. The process continues with the next test which explores another, more complex behaviour of the plant. This is supported by the initial implementation of the Controller as it makes it possible to stimulate the plant as a closed-loop system. In general, it can be said that

• with each new test a part of the real plant can be explored or known charac- teristics can be described; this is shown in Figure 6.3 by the increase of circles within the rectangles of Model and View; and

• with each modification or extension of the Controller, the number and the complexity of the realised requirements is rising; this is shown in Figure 6.3 by the increase of squares within the rectangle of the Controller.

As a result of this discussion, a second pattern for the test-driven development process can be defined:

Pattern TDD Design Process Context

A control system should be described by the MVC pattern. The Model is given by a plant with a measurable output and a controllable input, the View is given by a user interface. The characteristics of the Model and the View might be only partially known. A number of requirements exists, which describe the desired behaviour and features of the system from the user’s point of view.

? ? ? Controller View Model ? Controller View Model Controller View Model Controller View Model First test Second test A number of tests

Figure 6.3: Test-Driven Development as a Design Process

Problem

The Controller should be implemented. Solution

The Controller is realised with the following iterative process which is repeated until all requirements are fulfilled:

1. Create a new test which either represents a part of the View or the Model. The test can include a plant model, input stimuli and assertions for output variables. Typically the combination of in- put stimuli and assertions describe the desired behaviour of the test objective. Another aim of the tests is to explore the charac- teristics of the real plant or the user interface as shown in Figure 6.3

2. Run all tests. The new test has to fail.

3. Implement the Controller so that all tests pass. 4. Remove duplication.

To summarise, we have defined two patterns for the test-driven development of control system: the TDD Tuning Process and the TDD Design Process. Both pat- terns are complementary to each other. They describe the role of TDD in terms of control system design, while focussing on different levels of the system.