test suites
Joe Pfeiffer <[email protected]> Tue, 16 Aug 2011 20:00:25 -0600
| Newsgroups | gmane.comp.hardware.microcontrollers.gnupic |
|---|---|
| Message-ID | <[email protected]> |
I'm curious as to what strategies people use to create test suites for their projects.... I'm working on Yet Another Shop Toaster Oven (in addition to the standard computer-controlled solder reflow temperature profile, I want to be able to do things like powder-coat small parts in mine), so I've got more devices to deal with than most past projects: the thermocouple, the zero-crossing detector, the lcd, the timer, the keypad.... I'd like to get my code working in bite-size chunks: first get a test pattern up on an lcd, then interface the keypad..... the thing is, when I discover a bug in a later test (say I discover something was wrong with my lcd driver when I'm working on the keypad), I want to make sure my bugfix gets propagated back properly. OK, at some level the right answer is "make sure I do it", but I've been programming long enough to have nearly infinite confidence in my ability to make stupid mistakes. I started to work on a scheme to break up the code in to various include files for bit settings, constants, init code, driver code... and quickly realized that I was creating something that was massively unwieldy, and also (since I basically had to set things like the tristate registers with bit-by-but sets and clears) really inefficient. So now we come back to my question: what do you guys do? Lots of include files? Just one big chunk of source code (OK, it sort of can't be longer than 2000 lines so it isn't that big)? Some sort of m4-hell?