Course code: WEB-36
  • Years with company: 5
  • Years programming: ~10
  • Primary programming language: C, C++
  • Other programming languages: Ruby Python Rust
  • Unit test harnesses: Check - C CUnit - C CxxTest - C++ Boost::UnitTest - C++ Rust - built in to the language! Isn't just having your Python/Ruby script run without exception enough of a test?
  • Something else: I really enjoy music - both listening and recording. Since I also like writing programs for embedded systems, I have written a program for a Raspberry Pi that will rate the quality of a vinyl record on a scale of 1-10. I sometimes enjoy writing python scripts that generate music that only a computer could reproduce, but the music generated is never good.
  • Test practice now: C production code is tested using CUnit. We chose this library because it was very easy to compile with our custom toolchain and does not require an OS. C++ production code is tested with CxxTest. We chose this library because the python script that auto generates the test harness is easy to configure for use without an OS. All unit tests are run on the target system. This allows us to unit test things like GPIO assertions and interrupt handlers.
  • Target system: SoC with a custom MIPS processor.
  • Dev tools: Custom C and C++ compiler and toolchain (gcc patch). CMake for defining the build rules, which generate Makefiles we use for building. CUnit for C unit testing. CxxTest for C++ unit testing. Emacs
  • Build time: 1-5 minutes
  • Coding standard: We don't really have a coding standard. We use CodeSonar as a static source code analyzer/linter/good practices checker.
  • Function too long: If it can be made shorter and clearer. If it would be better split up into two or more separate functions. If it is a reroll of std::find. If it is a reroll of std::accumulate. If it is a reroll of std::transform or std::for_each.
  • Code reviews: Usually involve 4-6 reviewers, each reviewer spends 2 weeks annotating the code. We use a custom tool that allows reviewers to collaborate and make in-line annotations without modifying the code.
  • Code time: 50%
  • Test time: 40%
  • Debug time: 10%
  • Favorite thing about dev: Software is really about automating things. It's about spending x amount of time today to save yourself and others 10x amount of time or more in the future. My favorite thing about software is the feeling of time saved.
  • Least favorite thing about dev: I'm not convinced documentation is as important as everyone says it is. When there's too much, there's a sense of ease but you often miss the important parts. When there's not enough, there's a sense of panic but you can always elaborate more.
  • Tdd knowledge: *Write tests before you write code. *Unit testing should be able to hit ~100% code coverage. *Tests should follow the setup, act, assert pattern. *Unit tests should never depend on test ordering. *Test feedback should be immediate and readable.
  • Why are you attending: I'm interested in TDD, and especially interested in bringing it to embedded systems programmers. I've used it in my projects, and have had success bringing it to my group, but I want something to be a success story for TDD in other projects.
  • Back