i am still consuming the arduino website (it has a lot of pages and documentations, that are all helpful in one way or another). i found references to other similar projects to arduino. in particular, in regards to the sun microcontroller framework/platform, they have an emulator. i think (as mentioned by Anders2009) an emulator may be what i am looking for. i have played with the j2me (java micro, programming for mobile devices) framework, and they have an emulator. you program your code, and then you can perform unit test (with JUnit) and functional test (or QA test) with the emulator. the emulator may be modified to represent certain hardware specs (i.e. screen resolution) from reading your responses, arduino doesn't have an emulator.
pauls, the problem i have with writing a little code, then test, then writing a little code, then test (this type of lifecycle development) is that it is slow (time consuming) and prone to error (manual). your test will have to include uploading, turning on the unit (microcontroller + parts), running functional/regression/QA tests, etc... all of this is manual work and not automated (and anything that involves a human being testing is prone to errors, at least if the human being is me). also, when programming in C, one cannot help but to produce spaghetti code (code that is procedural, or more procedural than declarative), thus the code may not lend itself to unit testing frameworks.
on version control, i don't think the ide needs to have/support that explicitly. you can use CSV or SVN (svn is my choice) to version the code outside of the ide.
as for posting 300+ lines of code, there should be a rule to guide users in posting code. in the java forums, there's the idea of short self-contained correct example (www.sscce.org). i think we may have to promote this idea here too. when i've run into bugs, by preparing a sscce, i sometimes figure out the bug myself and never make it to the forums.
undo klein, you are right, you don't need any fancy unit testing framework, but why reinvent the wheel? the approach you suggested is what a lot of programmers have done in the past until these unit testing frameworks showed up. moreover, these unit testing frameworks (if they are mature) should automate the build, testing, and reporting for you (which i do not want to do, and would rather have something available out there to help me with).
i agree, it will be difficult to help coders that do not write their code to be unit testable (testable in terms of isolated units). but should a coder write unit testable code, we should be able to easily as possible help those coders out (don't you think?).
anders 2009, i like your first suggestion. i think that is probably the way to go given the limitations at the moment. i think abstracting out the hardware is contributes significantly to unit testing of code. in fact, that's what i do in my enterprise programming projects (abstract out the components, i.e. services/facade, that will interact with code units).
i understand what you are saying that once the code is deployed (uploaded), some bug will only arise in the working environment (i.e. fluctuating voltages). for problems like this (and problems related to observational effect), we use logging (which is equivalent to print statements). i wonder if emulators out there are helpful in resolving these types of problems?
also, i agree with what you are saying about hardware vs software testing. testing anything, is complicated (even some unit testing). the catalog of different types of testings are staggering (unit, functional, regression, etc...). but i think in this thread, i was more focused on code testing (in the taste of unit testing).
lastly, i don't know why i posted this thread in this forum, but probably because i thought maybe unit testing (or testing) was related to troubleshooting.
thanks all for the insight. very interesting discussion.