Course code: BARR-9
  • Years with company: 0.5
  • Years programming: 6
  • Primary programming language: C
  • Other programming languages: C++, Python
  • Unit test harnesses: None
  • Something else: I've always approached software from a Mathematics perspective, but that was only from the design standpoint. I'd heard of unit-testing years ago but didn't know much about it. Recently, I've inherited a legacy project and decided that my only way to get through this was to bring it all under test. I bought and read Grenning's TDD book over vacation (so I didn't do the exercises really) but the process of TDD as presented clicked with me. It seems like I was doing Math without proofs if I don't do TDD. Another thing I am adopting that I am very excited about is the QP Framework by Miro Samek.
  • Test practice now: Before reading Grenning's TDD book, I would write some "test" code that showed what I wanted my new code to do from a client standpoint. I would instantiate the thing, make some requests, etc, to get an idea of what I expected. Then I would write a flurry of code, possibly rewrite my "test" code and cycle that until it worked. These tests never used a test harness. Since I've ready the book, I haven't had the opportunity to write a lot of code but when I do, I try to follow the TDD-style in defining some tests more formally. I don't use a test harness yet but I am testing much lower-level functions now rather than testing very high-level things before (when they didn't work, finding out what was wrong in my 20-30 lines of code was where my time went).
  • Target system: My legacy project runs on an STM32F4 that interfaces with a Broadcom WiFi/BLE chip
  • Dev tools: Eclipse GCC in Linux at the moment. Considering IAR
  • Build time: Under 10 seconds
  • Coding standard: Nothing formal yet. I am investigating using Gimball on my project.
  • Function too long: I don't think there are any hard rules but there are red flags. That it can't find on the screen is a good rule of thumb that you should look at refactoring and abstracting your code s.t. the function can be "read" more easily.
  • Code reviews: Nothing yet. Team of 1
  • Code time: 25
  • Test time: 25
  • Debug time: 50
  • Favorite thing about dev: Logic puzzles. Also that great feeling when you designed something properly that you make a bold change and things haven't exploded.
  • Least favorite thing about dev: Being stuck with other people's crappy design choices.
  • Tdd knowledge: See above.
  • Why are you attending: To get my hands dirty with a test harness and learn more about how to find the seams!
  • Back