Course code:
WEB-33
Years with company:
5
Years programming:
14
Primary programming language:
C
Other programming languages:
Python
C#
Assembly
Unit test harnesses:
-Ceedling (Unity)
-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
Something else:
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.
Target system:
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.
Dev tools:
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).
Build time:
31-60 seconds
Coding standard:
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.
Code reviews:
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.
Code time:
20
Test time:
30
Debug time:
50
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.
Tdd knowledge:
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.