Course code: WEB-23
  • Years with company: 19
  • Years programming: >25
  • Primary programming language: C
  • Other programming languages: C++ C# Java
  • Unit test harnesses: gtest cpputest aceunit junit
  • Something else: We write code both for embedded systems as well as code for communicating with these systems. The code integrates with headers/libraries, and is build using the compiler and toolchain supplied/endorsed by the vendor. The architecture of the code is usually composed of an abstraction layer covering the differences between the various platforms and an application layer that is (should be) neutral to the platform.
  • Test practice now: The tests are partly unit tests and partly functional tests. Unit tests are run off-target. Functional tests on target. Test of algorithmic code and code integrating with the libraries offered by the vendor is tested on target. This approach has been chosen to ensure that differences in endianness, size of basic data types etc are sufficiently covered by tests.
  • Target system: The target systems are based on a number of different architectures. In general, debugging support is lacking - commonly reduced to output only when execution of the code returns 'nicely'.
  • Dev tools: Mainly Microsoft Visual Studio, gcc & IntelliJ
  • Build time: 5-30 minutes
  • Coding standard: Not formally. We try to avoid pointer arithmetic by writing functions encapsulating that kind of operations. Then we 'only' have to test those function to avoid many of the common pointer & overflow pitfalls.
  • Function too long: Do I have enough fingers to count the statements? ;-) -more seriously, all statements in a function should be at the same abstraction level and the function should so simple that a) no unit tests are needed or b) unit tests should be simple to write
  • Code reviews: Code is reviewed by a colleague - sometimes by the colleague sole - othertimes as show-and-tell seances.
  • Code time: 3/10
  • Test time: 3/10
  • Debug time: 2/10
  • Favorite thing about dev: Making stuff work.
  • Least favorite thing about dev: Debugging and Maintaining documentation
  • Tdd knowledge: Some prior knowledge - Have tried practicing TDD and have read (parts of) your book "Test-Driven Development for Embedded C"
  • Why are you attending: * To get a common language regarding test and code in our team * To get a common understanding on good/bad tests in our team * To refresh on TDD habits
  • Back