Test-Driven Development for C or C++ Training | Remotely Delivered via Web-meeting

This training course helps you build knowledge, understanding and skill in the engineering practices needed to build great C or C++ code. You learn how to build flexible and modular software with very few defects, software that can have a long useful life. We teach you how to prevent defects and how to keep code clean over years of evolving needs.

Are you still using Debug Later Programming? If you are tiring of chasing bugs, you might want to give Test-Driven Development a try.

TDD helps prevent defects! You'll discover that with TDD you can detect your mistakes and fix them moments after you make them. The payback is in the initial release, as you waste less time chasing bugs, and you check something in that actually works! You'll later see other benefits you get from test-driving.

This course is a good option for individuals trying to sharpen skills, or small teams where an on-site class is not a good fit. It is also a good way for your team to get started and to know us better.

Remote Delivery Options

  • Three-days 4-hours live-web-meeting
    • With additional video and exercise each day. One hour of required material and bonus exercises and demos.
    • Depending on questions and attendee pace, we may go a little longer than 4 hours.
    • Six month access to available lecture and demonstration videos.
  • Four-hour Remote delivered Legacy Code Workshop is available.
  • Available as a private course. In a private course there is an additional session where we can spend some time in your code and explore bonus content of your choice.

Dates, Times and Cost

We usually have one or two per quarter. Please contact us. and let us know your needs, or keep an eye on this page. We may be able to schedule a course that works for you. You can join our mailing list to be notified of coming public courses and new articles.. This hands-on course is $1000 per participant. If you have a group, ask us about a group rate or a private course.


Learning Model

We learn new skills by doing, not just reading, listening, and thinking. Engineers are not so interested in changing how they work if the change does not help solve some identified problem. We’ve found this learning cycle to be invaluable to attendees of our courses.

  • Present a problem -- problems motivate change
  • Present a potential solution -- the idea that may help
  • Demonstrate part of the solution -- remove ambiguity
  • Participant does an exercise -- learn by doing
  • Experience debrief -- identify and discuss both positive and negative reactions

In this course, we repeat this learning cycle, growing skills with each iteration. Our goal is to build new skills on top of the attendees' existing skills.

Audience

  • Embedded Software Developers
  • Software Developers
  • Technical team leaders
  • Managers that want to know more about the technology they manage

Day 1

  • Test Driven Development

    • Module Objective: Software developers make mistakes. Mistakes undetected become defects with potentially huge costs. In this section, attendees can learn the motivations behind TDD and how the short test-driven cycles may help prevent defects.

    During the debrief, we explore what people liked about TDD and what concerns them. There is usually a lot to like, but also serious concerns. It is important to bring the concerns into the open. This is a rare opportunity to reflect on how we work and to envision how TDD may help us improve.

    • Why Test Driven Development?
    • What is Test Driven Development?
    • The Microcycle
    • Exercise
    • Debrief
  • Adapting TDD to Embedded Software Development

    • Module Objective: Look at what is special about embedded systems programming, and some of the current industry-standard practice inefficiencies. We hope to show that TDD is well-suited for improving the embedded developer's product quality, as well as reducing some of the frustrations and waste when testing code in the target environment.

    • What is Special about Embedded Systems Development?
      • No hardware until late in the development cycle
      • Hardware with defects
      • Long edit, build, test cycles
      • Add your own unique problems here!
    • Running Tests the Development System
    • Risks of Development System Testing
    • Embedded TDD Cycle
    • The Role of Continuous Integration
    • Test Project Structure

    Day 2

  • TDD and Collaborating Modules - testing the code in the middle

    • Module Objective: The most valuable code you have (the code with the potential longest life) has dependencies. This code embodies what makes your product special. Automated tests help preserve your investment, allowing changes that have fewer unwanted side effects (defects!). We'll look at principles and techniques to guide developers in creating modular, testable, and tested embedded software. We'll introduce Spies and Fakes. You'll see how Spies and Fakes can fully exercise the code under test.

    • Object Oriented Principles Applied to embedded C or C++
    • Designing to interfaces
    • Information hiding
    • Substitutability
    • Spying on the Hardware
    • Faking the Time
    • Link-time Fake
    • Exercise
    • Debrief
  • Keeping Tests Clean

    • Module Objective: Tests have many valuable uses. One overlooked value of tests is that they are documentation. Tests provide an executable specification of the code under test. This document shows how the code is supposed to be used and how it is supposed to work. This document is unambiguous; it's code! This document warns you whenever the code differs from the specification. To get the most value from tests as documentation, tests must be written to be read and understood.

    • Tests as Detailed Documentation
    • Four-Phase Test Pattern
    • Given, When, Then
    • Arrange, Act Assert
    • Test Smells
    • Duplication in Tests

    Day 3

  • Test-Doubles

    • Module Objectives: There is more to test-stubs than the Spy and the Fake. We'll look at an overview of Test-Doubles and when to use them.

    • Taxonomy of Test-Doubles
    • Choosing Real or Test-Double
  • Test-Driving Next to the Silicon With Mock Objects

    • Module Objective: How close to the silicon can we get value from TDD? We can get to within a single C instruction of the hardware. In this module, we dig into The Mock Object. Mocks are great for faking the hardware while testing a device driver. Mocking has other uses as well and is quite powerful. It also hurts test readability so we'll look at when to use Mocks and when to use other kinds of Test-Doubles.

    • The Problem Solved by Mock Objects
    • TDD One Instruction Away from the Hardware
    • Specifying and Satisfying Expectations
    • Exercise
    • Debrief
  • Refactoring

    • Module Objective: As requirements and users' needs change, code must change. Design is so important, we don't just do design once at the beginning of the development effort. Design is a continuous process. We accept that changing design is dangerous, and the tests created by the test-driven developer provide a safety-net to lock in code behavior as your product design evolves.

    Refactoring (changing the structure of code, without changing its behavior) is a step in the TDD microcycle used when we need to clean up a mess. We'll also refactor code so that a new feature can be dropped in. This module provides and overview of the mindset and the critical skills needed to evolve designs for a long useful life.
    • Refactoring Defined
    • Critical to a Healthy Business
    • Critical Skills
    • Code Smells
    • Envisioning
    • Transforming
    • TDD's Positive Influence on Design

    For more depth in design and refactoring, you can follow our TDD course with SOLID Design and Refactoring for C or SOLID Design and Refactoring for C++

  • Working with Legacy Code

    • Module Objective: Now we face the reality that we have code that was not created with TDD. We've seen how TDD can help guide creating tested, modular and loosely coupled software. The reality: our code has problems. We don't have time to stop all feature development and retrofit our code base with tests. We'll look at the pragmatic approach to incrementally improving your valuable code base.

    • Legacy Code Mindset
    • The Cost of Doing Business
    • Where and How to Add Test and Refactor
    • Boy Scout Rule -- leave the campsite better than you found it
    • Incremental Improvement
    • Legacy Change Algorithm
    • Crash to Pass Algorithm
  • Wrap up Discussion
  • Optional Workshop for your Product Begins for on-site courses.

    • This course will get you and your team well on the way to applying TDD in your embedded C or C++ development efforts.

    Delivery Details

    How is this course delivered?