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!