Course code: WEB-29
  • Years with company: 5
  • Years programming: 3
  • Primary programming language: C
  • Other programming languages: Python Working on C++
  • Unit test harnesses: None in practice - have seen Unity and GoogleTest
  • Something else: I'm a electronics and firmware engineer - I do a split of hardware and software work, the software stuff has come in more in the last 3 years. I also do quite a lot supporting DevOps activities in the teams.
  • Test practice now: Verifying behaviour using memory-watching while stepping through (with code running on the target), logging trace events, and functional system testing on the hardware.
  • Target system: STM32 Cortex-M devices (M0 through to M7). Starting to work with Espressif ESP32 devices (Xtensa core).
  • Dev tools: IAR Embedded Workbench, VS Code and CLion for IDE / text editing etc. GCC and IAR compilers. Segger J-Link, IAR I-Jet hardware debuggers.
  • Build time: 11-30 seconds
  • Coding standard: Be consistent and fit in with what you observe of the standards already in the codebase. We don't have anything formalised!
  • Function too long: When I can't keep track of the mental model of what's going on anymore, or it becomes obvious that the function is handling more than one job.
  • Code reviews: We peer-review design documents as part of our process. Code reviews are initiated by the code author when they feel its needed (which happens for maybe 10-25% of the code).
  • Code time: 40
  • Test time: 10
  • Debug time: 50
  • Favorite thing about dev: It's open-ended, there's the opportunity to be creative. There's a craft to it - you can go a long way further than having code that functions as required, and have code that is transparently written, reusable and efficient.
  • Least favorite thing about dev: It's open-ended, and the number of techniques, design patterns etc can be overwhelming! It's hard to estimate time. It's hard to estimate how powerful the target CPU needs to be!
  • Tdd knowledge: It's an extreme programming concept. It's related to but not the same as unit tests. You write a failing test first, then make it pass.
  • Why are you attending: I want to get a practical start in writing unit tests, and get better at preventing bugs. If the process of TDD is a good way to do that, I'm up for it!