TDD Tuning Process

In the first book about test-driven development Kent Beck also presented a pattern language for test-driven development [66, pp. 123ff]. This language is divided into several groups: (i) for problems and solutions when a red bar or a green bar occurs, (ii) for testing in general, (iii) for testing with xUnit (see Section 2.2.2), (iv) for refactoring and (v) for the process itself. The book also covers the application of TDD to a subset of the object-oriented design patterns by Gamma et al. [72].

The fundamental pattern of TDD is Test First, which describes when a test is written, i.e. before the code is changed. Furthermore, all tests have to be automated (Test) and independent of each other (Isolated Test). The automation is typically realised by a member of the xUnit family of testing frameworks. The patterns of this family and the realisation with the slUnit testing framework have already been described in Section 2.2. As a consequence, we are able to write tests, automatically execute them and verify their results in a model-based development environment with a graphical programming language such as Simulink.

The pattern Assert First requires to write the assertions of a test first. This helps the developer to think about the problem which is to be solved. For instance, an assertion specifies that the rise time should be smaller than a specified value. Such an assertion leads to two questions: What is the input stimulus for which the response achieves the rise time specified? What is the plant model? The answers to both questions are part of the new test. The combination of input stimulus, plant model and expected results makes the test understandable (Test Data) as well as explicitly describes their relationship (Evident Data). For this reason, TDD does properly support the tuning process of controllers.

As an example, we can define a pattern for LQG control as it is commonly described in textbooks on control theory:

Pattern LQG control Context

The system is described by a state-space representation: ˙x(t) = Ax(t) + Bu(t)

y(t) = Cx(t) + Du(t) x(0) = x₀

Problem

The input variable should be defined by state feedback: u =_−Kx

K should be chosen to minimize a linear-quadratic performance index. J =

! _∞

0

(xT_{Qx + u}T_Ru)dt

Q and R define the tradeoff between the regulation performance and the control effort.

Solution

K is calculated by

K =_−R−1BTP

with P being the positive-definite solution of the algebraic matrix Riccati equation:

ATP + P A_{− P BR}−1BTP + Q = 0

To realise this pattern, the developer starts with some initial values for Q and R. Then, the performance index is typically not minimized by solving the Ricatti equation directly, but by using a numerical calculation to retrieve the values of K. These values are evaluated, for instance by a simulation of the closed-loop system, to check whether the system fulfils the requirements. If not, Q and R are modified and the calculation is started again. TDD can be incorporated into this process as it is iterative, starts with a requirement, and is finished when the actual behaviour matches the expected behaviour, as specified in the requirements. Thus a pattern is defined which describes the role of TDD in driving a tuning process:

Pattern TDD Tuning Process Context

A control system is given by a plant with a measurable output and a controllable input. A number of requirements exists, which describe the desired performance of the control system. The plant input is determined by a feedback controller.

Problem

The parameters of the controller should be chosen so that all requirements can be fulfilled.

Solution

The controller is realised with the following iterative process which is re- peated until all requirements are fulfilled:

1. Create a new test with a plant model, input stimuli and asser- tions for output variables. Typically the assertions are used in conjunction with one or more performance criteria.

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

3. Tune the controller with a (common) tuning technique, so that all tests pass. Example: Pole-Placement, LQG optimisation (see the pattern LQG control), PID tuning with Ziegler-Nichols.

4. Remove duplication.

In the context of Beck’s patterns, this role is supported by the pattern One Step Test. It describes how to choose the next test from the to-do list of tests. Basically, always a test should be selected which is suggestive and easy to implement. A constant and steady progress with only small steps should lead to a growing and evolutionary design, while preventing solutions which are too complex. Beck describes this as a known-to-unknown metaphor: The developer usually has some knowledge, which al- lows him to realise the first steps, but also to gain experience and draw conclusions about the further course of the development. This approach is directly applicable to control engineering. We typically start with a known method like pole-placement to implement a simple controller. This controller allows us to learn more about the closed-loop system, especially if the characteristics of the real plant are only partially known.

The to-do list of tests can be generated implicitly or explicitly from the set of requirements which should be implemented (Test List). Furthermore items might be added to the list during the development cycle because of a defect, either de- tected by another test or externally reported, i.e. not detected by automated tests (Regression Test). If a test already fails, a new test is only necessary if the reason of the failure is beyond the scope of the failed test. Moreover, the to-do list can be ex- tended by new tests during the development due to the known-to-unknown metaphor

(Learning Test) or other issues which are rather specific to the implemented software unit, but not included in the requirements. A common example is the check for a division by zero. To summarise, four origins of a new test exist as shown in Figure