Fake - Mac OS X Web Browser Automation and Webapp Testing Made Simple. | Hacker News Reader

Fake - Mac OS X Web Browser Automation and Webapp Testing Made Simple.

fakeapp.com

143 pointssant0sk136 comments

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.

I'd pay for it today. I've tried it out and it seems remarkably stable for an early-release product.

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.

Agreed about the name. I passed this link 3-4 times, and only ended up clicking on it because it made its way to the top of HN.

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.

SauceLabs do something like this, but for Selenium scripts.

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.

Try eggPlant by TestPlant: http://www.testplant.com/

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.

An open-source alternative to the eggPlant's visual-based testing tool is Sikuli: http://groups.csail.mit.edu/uid/sikuli

And I posted above, you can also use Selenium + Flex-Pilot to test Flash or Flex apps: http://github.com/admc/flex-pilot-x/ http://github.com/mde/flex-pilot/

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.

You absolutely can use Selenium to test flash (and flex): Gratuitous Landing Page: http://saucelabs.com/flex Source Code: http://github.com/admc/flex-pilot-x/

A lightning talk by Adam Christian about Flex Pilot: Part 1: http://www.youtube.com/watch?v=H_eECx0vgsI Part 2: http://www.youtube.com/watch?v=k3YeK_eowi0

Another tool you might want to look into for flash testing Sikuli: http://groups.csail.mit.edu/uid/sikuli/

why would someone name their app Fake? It makes me think its an april fools joke.

Not that I think the name is that great, but "fake" in this context is used to mean that the app can fake things.

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?"

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"?

fake is so much easier to spell in a url than "faux" or "pseudo". It's actually hard to misspell "fake".

"Pseudo" is a GUI interface for sudo: http://personalpages.tds.net/~brian_hill/pseudo.html

I actually like the name, it's descriptive and short and sweet. I think if he changes references to "Fake" to "Fake.app" it will remove any confusion.

Anyone have any experience with both Fake and Selenium that would care to explain the benefits of Fake?

app looks interesting.

features which I would ask for

a) headless runner

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

c) logging/debugging capability

d) and of course price it reasonably :)

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.

Celerity is based on Watir (similar to Selenium) and Ruby. See http://celerity.rubyforge.org/

With regard to b) support for languages other than AppleScript, ruby and python support is likely to work through Apple's Scripting Bridge.

Most AppleScript aware applications can be made to support ruby and python through this bridge:

http://developer.apple.com/mac/library/documentation/Cocoa/C...

I don't see what this possibly has over webdriver/selenium for anyone that can code.

While your comment is a bit snarky, I too wonder how it compares to Selenium before I give it a try when I get home.

I got the impression this was more for people who can't (or don't want to) code.

This is beautiful. I love that it saves its steps as an OS X plist file.

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.

I hope this continues to develop.

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).

SSL appears to be broken, sadly.

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.

See http://groups.google.com/group/fakeapp/browse_thread/thread/... for the workaround that got SSL working for me.

(Basically the app currently fails quietly if the SSL certificate doesn't validate, rather than prompting for action.)

Look at that, yet another browser automation tool that violates Google's TOS in its demo.

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.

red rock coffee ftw.

Maybe HN needs to supply more context when we hit the reply button so that we don't end up replying to the wrong threads.

Reply on news.ycombinator.com