I second the idea also. Tools like Squish have their place, but as a solo/hobbyist developer, I'd much rather put some faith in Apple's efforts to test that scrollbars scroll properly, buttons dispatch to actions, etc. and focus on how *my* code constructs views, binds data and generally assert that the state of my views is what I expect. On a related note, I just created my first custom view in macruby (just a throw-away tutorial app) and wondered what the best strategy for testing Cocoa graphics code might be. The most obvious answer would be to mock the critical parts of the API I am calling, but in practice I find that approach often leads to building a second implementation which isn't guaranteed to be any more correct than the code I am testing, and can become as much a liability as it is an asset. Does anyone know of a good model for testing graphics code that can actually account for how views *appear*? Best, Jeremy Voorhis On Tue, May 12, 2009 at 2:45 PM, Alex Vollmer <alex.vollmer@gmail.com> wrote:
On May 11, 2009, at May 11, 11:18 PM, Matt Aimonetti wrote:
Before I get too excited, I'd like to hear what you guys think and what you believe you need to write better code?
I love the concept, but have often found UI testing tools to be lacking. I think that's because in the past I was always hoping to write *unit*-tests for UIs which near-impossible to do without simply re-asserting the implementation (which makes for a terrible unit-test). Having seen the approach taken by Cucumber I'm more hopeful that this would get some traction. Hell, even to have something that would step through all the little manual scenarios automatically would be a great tool to have. So, yeah, Matt. I'm all for it! —Alex ---- http://alexvollmer.com http://moochbot.com
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel