Contributing Py.Saunter to the Selenium Project

[Adam Goucher]

Hello, Selenium Developers!

TL;DR
-------------------------------------------------
If the committers will accept it, I'd like to contribute the
IP for Py.Saunter to become part of the Selenium Project.

https://github.com/sebuilder/se-builder

Also, this is kinda snark, but now I'm really trying does force the larger governance question[s]

Cool Story:
-------------------------------------------------
By way of a brief analogy:
Py.Saunter is to the Selenium Remote APIS as the rest of a bike is to wheel.

The Selenium project provides two robust APIs for making a browser do fun things. But
they are useless themselves for any practical purpose without a runner, the ability to
get settings from some sort of config file, record output to a log file, etc. And those
are all significant hurdles for new users to overcome and often leads them to unnecessary
pain and 'selenium sucks' tweets before re-inventing the a wheel. Py.Saunter addresses
all those concerns and leads to a much more approachable user experience.

Moar Story:
-------------------------------------------------
I have been working on Saunter for about three years now in its current incarnation though
prior versions date before Selenum.  We believe Se Builder makes Selenium script creation
easier and more manageable. And due to its python implementation, Py.Saunter doesn't care
about platforms.

My goal in moving Py.Saunter to the Selenium Project is:
  * Engage the community to push Py.Saunter forward
  * Support the community better by making it easier for the growing
Selenium user community to make better, more supportable Selenium /
WebDriver tests
  * Dispel any clouds around Se Builder as vendor-ware that may be
holding back potential supporters / contributors from helping Py.Saunter realize the
potential I see for it

To be clear, Element 34 (me) plans to continue supporting the development of Py.Saunter.
In the short term we plan to:
  - Fix any issues keeping Py.Saunter from being fully Se-RC/WebDriver compatible
  - Continue improving usability

And longer term, the Selenium Project can expect Element 34 to:
  - Ensure Py.Saunter supports new browsers and mobile devices as the project does
  - Support the community by bug fixing, plugin development and documentation

Summary of the current state of Py.Saunter:
  1 - Py.Saunter now has full native support for Selenium 2 /
Webdriver. Se Builder uses the same user interface for Selenium 2 /
Webdriver as for Selenium 1, so users can use conveniently use a
mixture of both technologies.

  2 - The Py.Saunter code-base is now in a not-fully in a non-commercial state. It
 contains a reference to Sauce's OnDemand platform, but should other BaaS vendors
express interest, they can be easily added too.

 So, like I said at the top, if you, the Selenium committers, will
accept it, we would like to contribute the IP for Py.Saunter to become
part of the Selenium Project.  I'm happy to answer any questions that
come up.

Cheers,

- Adam Goucher
http://twitter.com/adamgoucher

-- 

[Mary Ann May-Pumphrey]

+1 

Your snark attempt has failed completely with this pysaunter user!   

And re: this....

 

> - Fix any issues keeping Py.Saunter from being fully Se-RC/WebDriver compatible

Please see https://groups.google.com/forum/?fromgroups=#!topic/saunter/ZbO10qBNwYQ

--mam-p

---

From: Adam Goucher <ad...@goucher.ca>
To: selenium-...@googlegroups.com
Sent: Wednesday, November 21, 2012 12:24 PM
Subject: [selenium-developers] Contributing Py.Saunter to the Selenium Project

http://twitter.com/hugs

-- 

--
 
 

[David Burns]

The reason why Se-Builder should be included in Selenium in my opinion is that its solving the multiple browser issue that Selenium IDE can't solve. The web is more than one browser! If we want to be able to push forward being able to work cross-platform cross-browser, especially for people getting into automation then Se-Builder gets us that. We may need to do education on when to use what tool but that is an education problem not a tools problem.

I know that you are gunning for some form of governance talk here so let's get it started. At the moment I only have three main questions

How does Py.Saunter give us cross-browser/cross-platform support that the currently python bindings don't?

Does this solve a real problem that perhaps the Selenium Developers should look at in terms of BROWSER AUTOMATION or is it solving a deployment/authoring issue?

You have previously stopped being the maintainer of a tool due to work commitments but said you will support Py.Saunter. Will support be short/long term?

David

David Burns
URL: http://www.theautomatedtester.co.uk/

--
 
 

[Adam Goucher]

On 2012-11-23 9:09 AM, David Burns wrote:
> The reason why Se-Builder should be included in Selenium in my opinion
> is that its solving the multiple browser issue that Selenium IDE can't
> solve. The web is more than one browser! If we want to be able to push
> forward being able to work cross-platform cross-browser, especially
> for people getting into automation then Se-Builder gets us that. We
> may need to do education on when to use what tool but that is an
> education problem not a tools problem.

'Education vs Tools' is kinda strawman-ish.

>
> I know that you are gunning for some form of governance talk here so
> let's get it started. At the moment I only have three main questions

I think the 'should selenium become apache or eclipse' thread I think
for a potentially better articulation of [some] of my concerns.

>
> How does Py.Saunter give us cross-browser/cross-platform support that
> the currently python bindings don't?
>
> Does this solve a real problem that perhaps the Selenium Developers
> should look at in terms of BROWSER AUTOMATION or is it solving a
> deployment/authoring issue?

Its the 'getting started' problem that it solves. I have seen too many
teams flail and have to backtrack and re-do work because they don't even
know the right questions to ask let alone to consider. Export from
Se-IDE/Se-Builder ... code away ... rework to page objects. WebDriver
... want to you Cloud/Grid ... rework to Remote. Which should be easy if
it was abstracted, but they don't know to do that. You might say that
this is a documentation problem, but if the documentation says 'in order
to start using this in a means known to work you need all these /other/
components and worry about all this /other/ plumbing before' then thats
not really solving a problem.

As currently un-consituted, there is /no/ distinction in the project
between BROWSER AUTOMATION as you put it and deployment/authoring.

> You have previously stopped being the maintainer of a tool due to work
> commitments but said you will support Py.Saunter. Will support be
> short/long term?

I suspect I would have found time to continue working on Se-IDE if it
wasn't for the fact the irony of working on a tool that I expressly told
people to uninstall and forget was not getting too great and distracting
from helping people success rather than aiming a shotgun at their feet
for them. Again, with the buckets of my own biases, when I teach Se the
first thing we do is uninstall Se-IDE, it gets the in way of being able
to succeed. Teams make headway when they forget it exists. (Actually,
its second -- getting rid of Eclipse is first...)

-adam