There really doesn't seem to be any good automated GUI testers out there. This is especially true for the main toolkit I use, Qt. But I just had an idea for relatively easy way to do it. It will allow recording and logging of events in the GUI, which is great since users never tell you what they REALLY did to make your program crash. You could then look at the logs to figure out how the user actually made the program crash/misbehave. You could also replay the log to take the drudgery out of testing your fix. Finally, you could create automated tests. That parts harder, as you would really need a nice test case editor to put together tests.
I'm really excited about this and want to start coding it RIGHT NOW, which is bad because I'm really tired and I need to get up and go to work in the morning. This weekend I'll start up the code, and release it to try to get other developers interested. I can really see it in my head. The last part of the project, the test case editor, is going to be really big. But I think it'll be really nice. The only thing is, where am I going to get the time to work on it? Then again, why would I want to do it? I'm an embedded systems guy with an interest in music. An automated GUI tester would be a great thing, but it keeps my from doing embedded and music stuff. The core library that makes it work is incredibly simple, though. I can write that, and maybe get other developers interested in writing the test case editor. That is the way open source works, after all.
Thesis
I just finished a paper on the scalability and performance
of multimaster I2C in sensor networks, and submitted it to
a conference. I'm going to start working on a paper
this week on error detection and recovery for I2C in
sensor network applications. That paper should come
together fairly quickly, it's just a matter of writing it
all down in a coherent fashion. My thesis advisor
says that if I take the information in these two papers,
combine them, and elaborate a little bit, I'll have my
thesis. Unfortunately, the deadline to submit a
final copy for 72-hour review is in less than 3
weeks. (I didn't know what any of the deadlines were
until 2 weeks ago.) And I don't have a
committee. D'oh!
AKO
We got some samples of the LTC4300-1 hotswap buffer, and
Chris got the smart hub layed out. We should be able
to build a smart hub pretty soon.
I got the transmit portion of the AKO stack done for ATmega uC's. The receive portion is kindof a low priority, since I'm working on that paper which will get rolled into my thesis. It turns out my problem all along was that the ATmega can detect/generate an "illegal TWI condition", which requires special handling to recover from. The part of the data sheet which tells you that is hidden remarkably well. Once I handled this special case, the code worked fine. I like the AVR uC's a lot better than PIC's, but the PIC's have much better data sheets.
I need to start updating the AKO SourceForge stuff with all the new AKO stuff. I just haven't had time with my thesis and working. Must increase caffeine intake...