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.
  • Back