[allanderek]

I think it's quite a nice idea, but I'm struggling to imagine myself using this. For a start, I want my tests in my source code repository. Secondly, I want to run my tests locally before I upload to production, perhaps even before I write the code to satisfy the tests.

I see that you have also developed a chrome extension so that one could run their tests locally. But that is essentially different from running your tests as a service. In this case you're essentially providing a testing library.

I could just about see myself writing my tests locally (perhaps using your chrome extension) and using the local tests for development and then uploading those tests and using a service to check a production server periodically. But I'm a little sceptical (why not just have the production server run the tests periodically itself?)

There may be some other uses for Web UI Automation as a service, for example scraping.

[wjg]

Definitely agree on the "tests in the repo" critique. That is a tough one, and a kink I've experienced as well. Some ideas I've had are webhooks to pull tests from a repo, but that's pretty janky and I'm not sure many devs/CTOs would be OK with that.

The extension actually has a crude way of uploading tests into your TestBeacon account, but that behavior is disabled/hidden for now since it is not quite production ready. This is convenient but doesn't strike at the heart of the repo issue.

I can definitely understand your general sentiment. The workflow is clunky right now, and making it not-so-clunky will be key for getting developers onboard.

I've thought about webscraping, but I feel a solution using these tools wouldn't stack up well with things like Mozenda. But I've done no research around that, so I'm running blind there. Maybe some simple machinery that goes to a URL, runs a Flytrap script, and then executes some sort of text extraction based on user's prefs.

Thank you again for your awesome feedback.