>>> On the subject of regression testing, do you practice test driven design
>>> (write the tests first, then the actual code)? It sounds like a great 
>>> idea,
>>> but I haven't been able to consistently/effectively apply it in the 
>>> embedded
>>> world.
>> Me neither.  I'm more likely to do it in desktop apps where I already
>> have an automated testing framework with a rich UI - or at least where
>> it's easier to write a unit test that spits out a readable log.  Most of
>> my embedded designs don't even have an LCD.
>>
>> I feel like it's worth exploring, though.  I "invented" it years ago
>> when writing utility classes in C++, and I've found it very helpful when
>> I've used it.
>>
>> In some sense, writing a detailed UI spec or even a clear state diagram
>> is fairly similar to writing a test case first - or it's useful for the
>> same reasons.
> 
> It's not quite the same. The whole premise of TDD is that the tests run 
> automatically, so you know right away when you broke something.

Right - though I make a minor distinction between TDD and continuous 
regression/unit testing.  I would say that tests cases can drive design 
effectively whether or not they're automated - though automating them is 
also hugely beneficial.

Gratuitous metric: On one 270,000-line desktop app, I have 209 test 
cases that run in under 8 minutes that cover nearly every feature to 
some degree, and are run before each check-in.

> I try to recompile and test the code manually (for example, by sending some 
> data through HyperTerminal to a comm module) every time I make a small 
> change. That's one of the reasons I like RealICE over ICD2 -- I don't have 
> to wait as long for the device to get programmed. This method is not as 
> bullet-proof as automatic testing, though.

Agreed.

This has got me thinking... I wonder whether it would be practical to 
set up automated unit tests using MPSIM?  Getting the output in an 
automated way is the main hurdle, I think.

Wouldn't be quite as good as testing the hardware, but a lot better than 
no tests at all.

>>> It would be nice if there was function overloading in C...
>> BoostC has that too.  Of course it's non-portable though.
> 
> Maybe I'll switch, but not anytime soon. :)  Too much code developed 
> already, too many projects still in progress, no compelling enough reasons 
> to switch.

Oh, absolutely - I wasn't evangelizing.

> Do you use a naming convention that identifies a funciton as belonging to a 
> particular module? I started prepending module name to the function name, 
> and found this technique to be quite useful. For example, you can tell that 
> Uart_Putc() is in uart.c, Adc_GetValue() is in adc.c, and so on -- withouth 
> having to Ctrl-Shift-F for it. 

Yes, I tend to do that.  Though sometimes I'll tend more toward names 
that sound like English phrases when available, so the name may not go 
first. E.g., in buttons.h:

void InitButtons(void);
void CheckButtons(void);
byte GetButton(void);

or in uiTime.h:

void ResetUITimer(void);
void InitUiTime_Timer0(void);
void InitUiTime_Timer1(void);
void InitUiTime_60Hz(void);
void UiTimeUpdate60(void);
unsigned char UiTimeInterrupt(void);

Always prepending the module name has the advantage that you can type it 
and then ask for auto-completion.  But somehow I still prefer "verb" or 
"verbNoun" (but the above examples show I'm not consistent about it).

> Private functions are declared static in a 
> module, and prepended with a p_.

I appreciate all of those Hungarian-style conventions... but I don't 
tend to use them.  First, because it makes it less English-like (I hear 
all the p's in my head); second, because it can get broken.  But I don't 
feel strongly about it.
-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist