sikuli-driver team mailing list archive

["Topagae@xxxxxxxxx" <question143226@xxxxxxxxxxxxxxxxxxxxx>]

New question #143226 on Sikuli:
https://answers.launchpad.net/sikuli/+question/143226

Heya Sikuli people! Just gotta say, Sikuli has saved my bacon quite a bit in the past. I helped leveraged it as the image search part of an automation framework that was able to automate flash games and it just made things work beautifully. I left that job and just acquired another where they want me to basically do the same thing.

I've always felt pretty indebted to Sikuli, it's developers, and it's users (Especially Raiman who helped me out on the job more times then he knows). So I asked my bosses if it'd be possible to open source the automation framework that I'm writing and they were actually pretty warm to the idea. It may have to be for non-commercial uses to cover our butts but that's still pretty awesome right?

I've only done a few lazy research days designing and hacking at it since it's not the only thing I have to do at work, but to give you a taste of what I've coded up before and what this framework will need to do here's a little overview.

The general goal of the framework is to use allow us to generically automate the test cases for any of our games. Using Sikuli's image searching I've been able to arbitrarily automate just about any game or product so that's obviously not too much of a problem. You can really do all that in the IDE, this framework is really just going to be a lot of nice features to build/maintain/test large amounts of scripts like this that someone who needs to automate a big product would need.

It needs to be pretty easy to run tests across lots of platforms so it's going to have a lot of logic about that, once again going to use different directories of images to intelligently navigate around with logic to pop open Virtual Machines with configurations we want to run tests on.

It's going to eventually need some good logging, currently I have a "Take a screenshot and shove in log folders!" function which is okay for seeing what's going on for now, but we're thinking of shoving some video recording functionality into the framework and just making videos of every script as it runs on the computer.

Besides the video logging and grabbing images from the web I've already made up a framework that does all this, and I'm doing it again now. But what else could it do? That's part of the reason I'd like to get it into the hands of ya'll.

Anyhow, to go a bit deeper here's some packages I've got currently in the prototype to explain some high level structure ideas.

images: I've currently got a nice organized directory file for storing all the images, but an interesting feature might be later to hook all images up to things on live webservers. Doing that we could link images in scripts to web files, and when that file gets updated, so does the script! This could reduce image maintenance a whole lot.

Library: The crux of the framework will be how useful all these nice little functions will be. I found that I could automate my games with almost all my calls (90%+) with JUST wait() and click(). Also going to be putting the bells and whistles here, like navigating to the right product to test, making sure you're on the right test configuration, recovery from errors or popups/abnormal behavior, logging and error handling. I'm also having product-specific library files that extend the main library file so you can have product-specific functions that don't bloat up the main file.

You could then run your tests like this: OS:windows/browser:firefox/suite:someTestSuite/game:Awesomegame100/scriptname

products: a package that contains packages for all your product test suites and test cases

products.someproduct.suites: I'm using JUnit to organize my scripts and tests in the hopes that it'll simplify organizing and test case reporting. So far it's looking pretty good. Anyhow, at this level you could have a collection of all your test suites for your product that you could run at any time.

products.someproduct.testscripts: this package contains a bunch of java files that all have JUnit test cases in them. Each test case is really just a bunch of sikuli calls that automate a piece of functionality, in my case for a game.

So I certainly haven't gotten too far, but I've built it before and I'm going to build it either way. I'd just much rather have it in the hands of others because I really believe in Open Source. I know for a fact lots of big companies have all reinvented the wheel and done all of this for themselves, I helped one of them. I think that's a damned shame and this might be a good opportunity to give a powerful tool to everyone. As for next steps I don't know. I asked a knowledgeable person who said a github/opensource organization project like launchpad or sourceforge would work. I could also maybe have a little branch here on the Sikuli launchpad if the Sikuli developers are okay with this little mini-project. I'm not too entirely sure what options to take, I could sure use some opinions on that.


Hey TLDR? Thanks for reading. If you got any feedback/questions/comments I'll be checking this often. I hope this idea/tool can really help some other people. I'd hate to keep it all to myeslf, again.

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.