Overall, this is my favorite paper so far this semester. It focuses on a tool that is released and being used in actual projects and not just as part of an academic environment which I quite like to see. The level of detail presented could have been better for some of the sections though. Their brief mention of how long it took to hook CHESS into an existing program was nice (and at one hour didn't sound too horrible) though it could have used with a more concrete discussion of what that involved. Running the tool against Singularity's boot sequence was an interesting touch, and that it found a bug is fantastic (how horrifying would it be to find your computer freeze or at least lose resources to a spinning thread.
The thing I liked the most about this product was definitely the robustness of the test platform. Its ability to semi-intelligently identify possible concurrency issues was cool, but by far the stand up features were the comprehensive test reports (enough to allow the engineer to target the condition that causes the error directly) and the ability to skip through the test set CHESS generates to a specific run is a great idea. I hate having to wait through several tests that I know will pass when all I'm looking for is to see if the changes I've just made actually fix what was intended. Allowing users to jump immediately to that broken test case is going to save quite a bit of time and aggravation. And 30 seconds for several thousand test case runs is not a bad trade off in that instance.
I suppose the only drawback right now is the effort that is required to extend this tool into new environments, and while I certainly appreciate the ability for this tool to work in the Windows environment I can already hear the calls to liberate this code so the *NIX can have its chance.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment