{"id":3328,"date":"2026-01-30T00:00:00","date_gmt":"2026-01-29T23:00:00","guid":{"rendered":"https:\/\/kunden.weissblaumedia.de\/microconsult\/2020\/12\/07\/rm_test-driven-development-1\/"},"modified":"2026-02-04T14:33:09","modified_gmt":"2026-02-04T13:33:09","slug":"rm_test-driven-development-1","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/rm_test-driven-development-1\/","title":{"rendered":"Test-Driven Development of Embedded Systems \u2013 Part 1: Test-First Approach and TDD Cycle"},"content":{"rendered":"

Test-Driven Development (TDD) is the implementation of the test-first approach in component testing and involves writing unit test cases before the actual implementation. Adherence to just three rules and a few tricks for dealing with the target hardware bottleneck makes TDD possible even for embedded systems.<\/strong><\/p>\n

<\/p>\n

Many agile development frameworks refer to the test-first approach, which, regardless of the test level, is based on starting with testing as the first step towards the actual realization of functionality \u2013 that is, testing at a time when one is still busy with the "what" and the "how" is still ahead of one.<\/p>\n

The test-first approach in the different test levels<\/h4>\n

The costs of finding and fixing errors increase significantly as a project progresses, sometimes reaching enormous levels for field fixes. The test-first approach aims to uncover errors as early as possible by creating and running tests even before the product or system being tested exists. Test-first can be applied at all testing stages, from acceptance testing to component testing and software implementation using test-driven development (TDD).<\/p>\n

Test-First in the Acceptance Test<\/h4>\n

In agile development models, such as Scrum, user and system stories are typically used; backlog items to be developed are derived from these. The test-first approach at this level means that acceptance criteria are determined before considering how a backlog item can be implemented. These acceptance criteria must be met for a backlog item to be marked as "done" during sprint acceptance. Defining acceptance tests before actual implementation results in more complete and testable user\/system stories, as all conditions, inputs, and expected outputs specified in the test cases are incorporated into the user\/system stories. Effort estimation based on the backlog items is therefore easier and more accurate.<\/p>\n

Test-First in System Testing<\/h4>\n

System testing focuses more on load and stress tests in an environment as close to operational real-world conditions as possible, in order to demonstrate the non-functional quality characteristics according to ISO\/IEC 9126, namely reliability, usability, efficiency, maintainability, and portability. Here, too, the test-first approach means specifying and creating the system tests before the product itself is developed. The creation of the system test cases often results in technical requirements that can be incorporated into the product planning and design as early as possible under the heading of "Design for Testability.".<\/p>\n

Test-First in integration testing<\/h4>\n

Integration testing requires a phased approach, in which more and more components are gradually combined for testing. The test-first approach involves creating integration tests step by step, along with the expected results, before the components even exist. This allows interface problems to be detected early and resolved during the design and implementation phases. Interface specifications are defined with testing in mind, progressing from simple to increasingly complex interfaces and resulting in particularly lean and easily testable interfaces.<\/p>\n

Test-First in Component Testing<\/h4>\n

Implementing the test-first approach in component testing means writing unit test cases before the actual implementation. This is precisely the goal pursued by the Test-Driven Development (TDD) approach, albeit in small steps. While TDD, originating from Extreme Programming, is not part of the Scrum development framework, it integrates seamlessly.<\/p>\n

In Scrum, sprint backlog items are broken down into tasks for completion. The smallest typical granularity of effort for a task is one development day. The Scrum framework doesn't go any lower than that. This is precisely where TDD comes in, breaking tasks down into small steps that are processed iteratively \u2013 naturally, following the test-first approach: test first, then implement.<\/p>\n

TDD cycle<\/h4>\n

In Test-Driven Development (TDD), code is created along with unit test cases in the TDD cycle through small, iterative microsteps. Each TDD cycle focuses on a self-contained piece of functionality, such as a function in C, a C module, a C++ class, or a method of an object. An iteration in the TDD cycle consists of three main components and lasts only a few minutes \u2013 the shorter, the better.<\/p>\n

The three main parts are called Red, Green and Refactor:<\/p>\n