Course code: WEB-35
Years with company:
Primary programming language:
Other programming languages:
Unit test harnesses:
Many including CppUTest googletest, boost, assert, unittest.py junit, nUnit, custom, ...
I like the challenge of getting unit tests working in legacy code. I'm humbled that more programmers don't currently do TDD.
Test practice now:
Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing.
Arduino, embedded linux, embedded Windows, desktop exercises.
Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio
varies by project. Usually minimally specified and syntax vs semantics/design. Rarely "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter et al
Function too long:
When it's hard to quickly understand or could be clearer if refactored. Could be as little as a one-line wrapper with a good intent-revealing name. Probably no bigger than one screen full.
varies by project, from zero to by weekly to pairing
Favorite thing about dev:
Quick tangible progress. Quick feedback. What software enables in the world.
Least favorite thing about dev:
Feeling on not fully understanding things. Risk of small mistakes having big consequences. The common perception that programmers are already doing the best they can using limited approaches.
I've studied and practice TDD. I use it on my projects. I use it on client projects when possible. It's common that I'll demo some examples in a code base but that the teams will not take it and run. Reasons cited include: no time, too hard, fragile.
Why are you attending:
To grow more fluency with TDD for embedded. To grow techniques. To learn ways to explain and motivate the use of TDD.