We have our self-paced TDD Training in beta.more...
Self-Paced Test-Driven Development for Embedded C/C++ Training
This training course helps you build knowledge, understanding and skill in the engineering practices needed to build great 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 skills to help prevent defects and keep code clean for a long and useful life.
We're working on a full C++ version of this course. In the mean time, we can include the currently available C++ content with your C language course.
Is TDD right for you? Do you answer "yes" to any of these questions?Do you think debugging is a natural part of programming?
Congratulations, you are practicing Debug-Later Programming! -- Don't put it on your resume yet. Let's compare Debug-Later Programming next to Test-Driven Development.
The problem with Debug Later Programming is that the mistakes go unnoticed. It may take days, weeks or months to get back to the developer. By then so many changes have been made that there is often no clear root cause. The programmer's only recourse is to start debugging.
How long does it take to find to cause of a bug? In general, that is an unanswerable question. You've had releases held up for defects. You've jettisoned valuable features because of defects. Debugging, an inherently unpredictable activity, can destroy the most carefully crafted plans. Bugs are expensive. They can put you out of business. They can cost you your reputation.
In comparison, with TDD there is immediate feedback. For new code, mistakes are put in your face. For the future (tomorrow and beyond), the tests provide a safety net, so that when the changes roll in, your tests immediately tell you of unintended consequences. This immediate notification helps prevent bugs. Not all bugs, of course, but most of them.
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.
Are you tired of chasing bugs?
Test-Driven Development (TDD) helps you prevent defects by putting mistakes in your face as you work. It's humbling and worth it. TDD will save you hours and days of aggravation. With TDD you work in a tight feedback loop, adding a failing test, then writing just enough code to pass the test. This cycle continues as you exercise and confirm each path through the code.
This probably sounds backwards or crazy. You will find it is an effective and natural way to work. As a bonus it's rewarding and fun too!
With TDD, development and test automation are part of every day. Each iteration you add new features and capabilities. The tests form a safety net that notifies you when your code no longer meets the specification designed into each test.
For more information about how TDD can save you from the defect chase, read The Physics of TDD.
Are you frustrated with deteriorating code?
Code change is inevitable. But how do you make changes to code that ensure the design stays clean? The test safety net, woven with TDD, allows you to safely refactor your code and keep your system from deteriorating. You will learn to identify code and design problems, envision better solutions, and keep your code working during the transformation.
Did you know it is easier to keep a system working, than to fix it after your break it!
Our courses will help you learn the critical skills needed confidently evolve existing code without introducing new problems. See my 2016 Agile Technical Conference Talk, Refactoring: Three Critical Skills. You can find the slide deck here.
Is your schedule tight and you don't have hardware to test your code?
It is so natural for embedded developers to live with this pain. When hardware and software are concurrently developed, too often hardware is delivered late in the development cycle. A miracle is expected when the two come together. But there are no miracles in this line of work. If you rely on your target as the sole vehicle to test your code, get ready for pain and delays.
James first saw Test-Driven Development in 1999. His jaw dropped! Could TDD could help relieve the pain caused by the target-hardware bottleneck? Could we get code working in an off-target test environment before hardware is ready?!
James lived with the pain for the first twenty years of his career. No more though, and you don't have to either.
Our courses will help you learn to design for test. You'll have more than testable code, you'll have tested code! You'll see how TDD and off-target testing can help you break the target hardware bottleneck. You'll separate your core product behavior from hardware implementation details. Nearly for free you get future portability helping your code have a long and useful life.
Read more about progress before hardware here.
Are Scrum and Agile painful for you?
Scrum and agile have quickly become the status quo in many companies. Agile's short delivery cycles can seem disruptive and chaotic, particularly for those of us who grew up on waterfall. Many companies ramped up by training a few scrum masters, leaving the developers to just "figure it out" on their own.
Adopting iterative management, planning, and delivery -- and not investing in iterative engineering -- is a recipe for pain.
What is your pain level?
Can you spot these common symptoms of agile-done-poorly?
- Iteration / sprint deliveries are more often missed than completed.
- Developers feel rushed and micromanaged.
- Developers feel pressured to deliver a poorly engineered product.
- Code quality suffers.
- Morale is low.
- Releases are missing key features.
Want to stop the pain? The road to recovery can begin by attending our training. As you grow your iterative engineering skills you'll move the pain needle toward the green end of the spectrum. Adding iterative development to your skills can do more than just relieve pain, you'll enjoy developing even more.
With Wingman Software, you'll learn the engineering techniques needed to deliver working products with long useful lives. You'll start on a path to a more enjoyable career doing the things you like most: solving problems, programming, and delivering useful products. You'll also avoid the pain of delivering defects, debugging, and low morale.
If you answered yes to any of these questions, we can help.
Many developers before you have had those pains relieved by learning and practicing TDD. TDD can help you and your team deliver better software faster.
Test-Driven Development, Why?
Test-Driven Development, What is it?
Self-Paced Training -- Early Access Open!
This self-paced version of our will lead you through a learning experience using a series of
- Video presentations.
- Video demos.
- TDD programming exercises, with hints and demos to follow along.
- Debrief and reflection questions.
- Video explanations of common questions and concerns.
Our self-paced course is a great option for digging in and experiencing TDD yourself. You don't need to wait for our schedule to match yours. You don't have to get up before dawn or stay up late at night to match our time-zone reach. You can take the course when it is convenient for you.
The self-paced course lets you go a lot deeper into the exercises than we can in the instructor led course, where there are always time limits. To get the most out of this course, take it with someone else and do the exercises together.
Plan your pace
You can choose a training approach that works for your situation. Start right away and either immerse yourself or pace your progress over a few weeks.
- Immerse yourself -- Complete the material over a single week.
- Pace yourself -- Complete the material over several weeks. For example:
- Week 1 -- Module 1 -- Your first TDD
- Week 2 -- Module 2 -- TDD and code with Dependencies
- Week 3 -- Module 3 -- Test Doubles and Mocking the Hardware
- Week 4 -- Module 4 -- Refactoring and Legacy Code
Have a colleague signup so you can work together on the exercises. -- I can setup a cohort that makes collaboration a little easier.
After the training, start putting your knowledge to work in your product development effort.
We can help you after the course with a workshop in your code.
The cost is $1000 USD/attendee. Introductory offer $500/attendee. During the introductory period, we'd like you to keep track of issues and agree to a debrief session or two so we can get your feedback. -- This is a limited time offer can change without notice. Sign up
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.
- Embedded Software Developers
- Software Developers
- Technical team leaders
- Managers that want to know more about the technology they manage
Agenda by Module
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.
- Why Test Driven Development?
- What is Test Driven Development?
- The Microcycle
During the debrief, we explore what people liked about TDD and what concerns them. Most attendees like the experience, but also have a serious concerns or two. 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.
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
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
- Designing to interfaces
- Information hiding
- Spying on the Hardware
- Faking the Time
- Link-time Fake
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
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
Refactoring -- Overview
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
- 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
Working with Legacy Code -- Overview
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
This course will get you and your team well on the way to applying TDD in your embedded C development efforts.
Let me know if you are interested through our contact form. Purchase includes access for at least six months.
A blank page can be very intimidating, even for a Test-driven developer. Where do we start? Write a test, right? Not always.more...
Here is a short interview with James about TDD and embedded software from the deliver:Agile conference last spring.more...
James participated on these social media platforms.more...
Do you have some time to do a simple programming problem in C or C++ for my research?more...
My long-time good friend (Uncle) Bob Martin and I have fun programming together firing tracer bullets for distributed water pressure measurement system.more...
Here are a couple reviews of our TDD for Embedded C training.more...