Course code: WEB-33
Years with company:
Primary programming language:
Other programming languages:
Unit test harnesses:
-IBM Rational Test Real Time
-An in-house custom framework
-I used cpputest when going through the embedded TDD book, but not for real work
I started my career as an embedded firmware tester, although I was isolated from the developers and only did unit and integration tests for the product. This gave me a bad taste for unit testing initially, because it was overly mechanical (just write tests to get full coverage). After changing jobs I read your TDD book and it made a lot of sense, and now I'm the "testing guy".
I am a fairly careful/deliberate programmer, and I prefer to have a deeper understanding of what I am working on.
I like studying new and different programming languages as a hobby (my latest interest has been Forth). I also like studying human languages (Esperanto, Spanish, Mandarin,...)
Test practice now:
For re-usable/library code I use Ceedling to do some unit testing, but it has been difficult to find a way to use this on our production code.
Most SW testing is manual bench testing with a debugger, and integration/system testing in the product. I've used Robot Framework with python to do some automated integration tests on our products, but I would say that the majority of testing is done using a debugger or python scripts.
The products I work on are embedded controls for electric motor protection devices or variable frequency drives.
We run on bare metal with a cooperative scheduler.
Vendor-provided Eclipse-based IDEs and build tools with various debuggers depending on the target.
I use python for writing test scripts/tools.
I use vim for more involved coding (I use Windows Subsystem for Linux to get vim and other Linux tools).
My coding standard is pretty simple. It uses prefixes to functions to identify which file they come from, and variables have prefixes based on scope. No globals. I try to keep code modular with a single focus.
Function too long:
If it does too many things, or nests too deeply. Sometimes a flat switch-case for a state machine might be long but fairly simple, so it depends on complexity.
I use Microsoft DevOps to do code reviews via pull requests with git.
Typically I look at diffs if I am familiar with the codebase, or I will look at the whole files more if I am not familiar with the code.
Favorite thing about dev:
I like solving problems and making things work. I also enjoy making tools to make my life easier. I like the rush when I solve a complex bug (although wish I didn't have to do that as often).
I generally like understanding how things work.
Least favorite thing about dev:
I don't like the unpredictability and stress associated with debug-later development. I feel like SW testing is under-valued in the embedded sphere, and I see many instances where it would have saved a lot of time and money.
I have read your TDD book and sparingly used Ceedling for several years, but I wouldn't really say I have truly used TDD outside of one small project and a few library modules.
Why are you attending:
I want to learn how to apply TDD more in my day-to-day coding, not just for frameworks/libraries. I see a lot of potential to benefit from more testing, but can't find a path to achieve that.