TDD for Embedded C++
2021-01-15 00:02:26 UTC
Most useful learnings:
The most useful things I learned were how a Mock works and how to apply TDD to legacy systems. I was exposed to Mock via a Clean Coders video, but I didn't understand the difference between Fake, Spy, and Mock. After your presentation and exercise on Mock, now I do. Applying TDD to legacy systems didn't make sense until you showed us your automated way to do it. Getting the test to compile and link with the legacy code is the biggest stumbling block and you shared a clear way to do it. Even if I have to do it manually, I now know an straightforward way to add TDD to legacy code.
Concepts v exercises:
Presentation v discussion:
The only improvement I can see is to incorporate an extra short break or two. Granted we were working remotely and could walk away when we wanted, but I didn't want to miss the information being presented. I usually waited until we started the exercises for my bathroom breaks. This put me a little behind the others, but I was able to successfully finish the exercises after the class ended.
The exercises were very helpful. They provided opportunities for us to stumble and make mistakes. But at the same time the exercises kept us fenced in by the files we were not changing, preventing us from getting too far off course.
My only suggestion is to add a few hints for the Mock exercise. I had difficultly understanding the first step, possibly because I was confused between starting Part 1 and Part 2. Once I got the first two tests working, the concept clicked and it was smooth sailing for me.
The instructor is top rate!! This was the most useful software class that I have ever attended. I can immediately apply the things I learned.
The quality of the exercises show that a lot of thought was put into creating the course. The circular buffer, the light controller, and the Mock example provided the right level of complexity to teach us the concepts and to identify the pitfalls when we hit them. During the presentation, I liked that the instructor walked through examples, intentionally making mistakes that we might make, giving us insight into the thought process and teaching us how we would correct the same mistakes.
Bring it on!
If I was working by myself, I would start tomorrow! Unfortunately, our engineering management wants to develop code with our team. We are told that we are using an "agile" approach to accommodate changes, but we are really just not taking the time to understand what we are building. So far, in three months, we have changed processors, changed languages (to Rust), changed the number of processors in the system, and been told that we don't need to know the requirements to get started coding. In the last three months, we have accomplished virtually nothing on our project. This project is a disaster and the demoralized software team is no longer making suggestions on improving the situation. This is not the fault of TDD or the course, this is a management issue. Perhaps I can use my TDD knowledge when my manager quits or at my next job when I quit.
Challenges to applying:
We are forced to work as a Mob on a single, shared computer. Unfortunately, our manager codes with us and our director wants the boss to take a leadership role. The intent of the Mob was to share our skill sets, but that has not happened because of the large experience and skill disparity between individuals. This has caused frustration in dealing with people who are unable or unwilling to get out of their comfort zone and learn something new. Also, when your boss is in the Mob and trying to take leadership, it's impossible to get one's ideas weighted equally. We tried explaining dependency injection to the boss, but he didn't understand C++ and did not consider dependency injection to be important. We gave up trying to improve things in the Mob environment.
The remote delivery was more effective than I thought it would be. The presentations were well-paced, skipping slides as needed, and we had copies of the presentation for later review. I thought having each of us work independently on the exercises, with instructor hints, worked out better than pair programming would have. Two confused people working together is not any better than one confused person. The dashboard was surprisingly efficient at letting the instructor track our progress and our stumbling blocks. I appreciated that the instructor let us struggle a little with the problem and then provided help without our having to ask. Otherwise, we would have wasted time continuing down the wrong path and would not have learned from our mistakes.
Legacy code workshop:
Recommend to others: