The application looks very nice. I wish there was more info about when it will be on sale, rather than just saying that it will expire in August. I don't want to get dependent on it and write my Applescripts just to find them useless when the demo expires.
Yes, looks pretty clean and intuitive. Here are some caveats are see thought:
- I don't really like the name Fake.. I thought it was a lying page or something..
- As I see it.. it kind of make it extremely intuitive for a newbie user to add action.. however, how this newbie user will know the id in the post field..? (Ok, maybe those users will only use the "click" action).. but still, it could be good to separate the action into a beginner mode and advanced mode.. this will make it even easier for no-tech people to use the application.. and maybe make it more powerful for developers to build test suite, etc.
What would make this truly epic would be if they offered a secure hosted subscription service that allowed you to upload a script you built with the desktop app and either:
a) run it on a hosted Mac Mini at a specified frequency, with a billing rate based on number of actions/frequency of script execution (aka, someone with a 30 step script who wants their script to run once an hour pays more than someone with a 5 step script who wants their script to run once a day)
b) execute the script on their hosting via a callback url, so I can hook this up to my CI server
This plus flexible notifications (email, SMS, Campfire) would be huge.
If I understand how this works, there is a clear use case for using this over say Selinium: flash interaction testing. so assuming you have a fixed dimension site in the fluid browse, you could interact with flash widgets... Right? or am I totally off track here?
For most other functional testing I'd stick to webrat that I can bake into my build script.
But flash testing...I really want to crack that nut.
We're using it, and it's the only solution we've found that works well for Flash testing. Costs a bundle, but was worth it to automate our (mostly Flash-based) app...
Also, it doesn't look like Fake would be able to interact with Flash/Flex apps, based on the screenshots. Looks like DOM scripting to me.
I'm not sure I follow you? This app doesn't have any ability to "record" (especially not click coordinates). Rather, you assemble your actions by drag-and-drop only. Selinium is far more full featured browser automator. However, this power comes at the cost of simplicity. Selinium is broken up in to three separate components that must be installed and work together in order to function. This isn't a bad thing. It's just far more complicated than Fake.
It matters a lot more what it sounds like to people who've never heard of it before. It's like if I were to create an app called "Malware", people aren't likely to dig deeper and find out it's a random Malcolm Reynolds quote widget.
"Fake" is such a negative word, were better names taken? "Faux"? "Pseudo"?
The name is OK I suppose, but it makes for an incredibly confusing headline on any sort of social network. Certainly don't start anything with "Fake -" or the first question everyone will ask is "is this real?"
b) applescript may be usable but could it be integrated with ruby or other programming languages, that I way can make it a driver for my current testing flow
Doing headless integration testing really is superior. Requiring one machine per concurrent test isn't scalable. Sure, works great for your weekly/daily test. But if you want integration testing to run at every commit it's not going to work.
I've done some experimenting with Celerity (headless integration testing with JS support) and it works quite well. Can even emulate CSS and it scales much better. One thread becomes one test. So running 50 tests in parallel on one machine is no problem. This really is a requirement for me if you want it to work with CI.
I believe this is a consequence of using the CoreData defaults. I hope the author leaves it this way. That would allow me to output automated tests from scripts.
At the moment it seems there is a need to know the ids/classes of your entire page by heart - or resort to looking at your own source, it would make it _much_ less painful if when you click in a box that expects an element ID that your cursor could then be used to click an element, to generate the xpath (like webinspector/firebug).
Interesting app though - have been a heavy user of Selenium for testing but building the scripts has been time intensive and generally is done by the QA team rather than by devs. If the UI for building these tests gets better, then devs may end up building tests for themselves rather than expecting someone else to do it.
I didn't know what you were talking about, so I looked it up. I guess you're referring to this:
> 5.3 You agree not to access (or attempt to access) any of the Services by any means other than through the interface that is provided by Google, unless you have been specifically allowed to do so in a separate agreement with Google. You specifically agree not to access (or attempt to access) any of the Services through any automated means (including use of scripts or web crawlers) and shall ensure that you comply with the instructions set out in any robots.txt file present on the Services.
Yeah, sorry about that, I guess that would have made my comment a little less worthless. My interpretation of that clause includes tools such as this, and though it is hardly some gross violation, I do find it amusing.
I know Selenium RC does the same thing in sample scripts for some of its bindings, and I'm pretty sure I've seen it in other tools as well.
i'll be curious to see how many people use this for testing and how many end up using it for more nefarious purposes like screen scraping or rigging TIME's 100 most influential people poll.