Course code: NEPT-1
  • Years with company: 12.5
  • Years programming: 18
  • Primary programming language: C
  • Other programming languages: C#, assembly
  • Unit test harnesses: Unity very little, LDRAUnit very little
  • Something else: I'm a father of three wonder kids, Grady (10), Gwyneth (3) and Griffin (1). We love the water and spend a lot of our time on the lake.
  • Test practice now: We have something we call CBAT (Continuous Build and Automated Testing), which includes all of automated builds that are executed within TeamCity. Once the builds are complete we run unit tests (for those that have implemented them) then integration tests on the target devices and monitor them with various lab equipment to measure performance, current draw, test interfaces, pre-compliance testing, etc. We also do separate design validation tests in our Electronics Lab, which are sometimes manual in nature. We also have an SQA department that does testing from a customer perspective.
  • Target system: Some products use microcontrollers (ARM M3/M4, 8051, MSP430) running bare metal code. The other end of the spectrum are microprocessors (BlackFin) and FPGAs
  • Dev tools: IAR, Keil, PC-lint, RSM, Doxygen, JTAG debuggers, oscilloscopes, protocol analyzers, spectrum analyzers, DC current analyzers
  • Build time: 11-30 seconds
  • Coding standard: We currently have an existing embedded coding and best practices document that is going through internal updates this year to condense and clarify. We expect to land on implementing the Barr Group coding standard possibly some aspects of MISRA.
  • Function too long: Page or so is about the max. Also high essential essential cyclomatic complexity could trigger that a function is too long.
  • Code reviews: All code merged to mainline is done via Pull Request, which generates online review on our internal Bitbucket server.
  • Code time: 60
  • Test time: 25
  • Debug time: 15
  • Favorite thing about dev: It's a new challenge every day that can be solved in an almost infinite amount of ways. Solving problems is fun.
  • Least favorite thing about dev: There's not much I don't like about developing SW. Probably the amount of time spent on DV testing and documentation.
  • Tdd knowledge: I know the idea is to create the tests first then write the code to pass the tests. I've managed people working on implementation of unit tests (not straight TDD) on a few development projects with mixed results.
  • Why are you attending: I'm attending the class because I want to understand exactly what TDD has to offer and how to effectively implement TDD and unit testing within a department so we can trial it on an upcoming project to gauge its effectiveness.