The path to 3.0

[Simon Stewart]

Right. It's been a while since 2.0 (July, 2011) We should get the show on the road for 3.0. Suggested highlights:

* Remove RC from main distribution. Make available as a legacy package. Cease development in 4.0

* Include Builder alongside IDE. Move to legacy package in 4.0

Removing RC also implies removing the html runner which people use for running IDE scripts. We may want to put together an alternative runner that delegates down to WebDriver to handle the common case where people aren't using user extensions.

Timeline: 

* We need Builder in the tree before we can start this

* We should make it easy to get hold of the Safari driver

* We may need the alt-runner for IDE scripts.

Comments? Feedback? Other things to consider?

Simon

[Adam Goucher]

> Removing RC also implies removing the html runner which people use for
> running IDE scripts. We may want to put together an alternative runner
> that delegates down to WebDriver to handle the common case where
> people aren't using user extensions.

There are a couple floating about on GitHub that do this -- including
one that was worked on through GSoC. It is almost time to think about
GSoC again ... I'm not going to be the point person for it, but that
seems like a nice solid thing for someone to work on.

-adam

[Simon Stewart]

Any other comments, other than Adam's? Jason? Patrick? Paul?

Simon

[Alexei Barantsev]

-1 to remove RC from the main distribution until we cease its development.

1. What's the purpose of a separate distribution? What goal do we want to achieve by this act?

2. How to distribute WebDriverBackedSelenium? In the main distribution with duplication of some RC code? In RC distribution with dependency on WebDriver?

I suggest to cease RC development in 3.0. We have already stopped to fix bugs in RC, and I don't see anyone is going to change this state. RC is already frozen. No need to prolong this coma. Anyone who wants to use RC can stay with version 2.x

Regards,

-- 

Alexei Barantsev

Software-Testing.Ru

Selenium2.Ru

[Kristian Rosenvold]

To me "3.0" sounds like where we remove all the browser supports from the main distribution. 

Kristian

2013/1/16 Simon Stewart <simon.m...@gmail.com>

Simon

--
 
 

[Simon Stewart]

First some clarification: we've not stopped fixing bugs in RC and it's not completely frozen, we've acknowledged that we're no longer working on new features for it. We're still making sure that it works in the recent browser releases, and that's important because there's a vast number of people who are using both RC and IDE. Although we think we've been doing a good job communicating this change in focus, lots of users still aren't fully aware of what's happening and lots more need time to migrate.

With that in mind, the reason for the separate jar is to make it clear that RC is now not the primary focus of the project, but to make it easy for people to continue using it. The WebDriverBackedSelenium, being an implementation of the RC APIs will live in that same extra jar. 
 

Simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Simon Stewart]

That's 5 :)

[Luke Inman-Semerau]

The homepage of SeHQ should state our intention of deprecating RC (before we actually do it), what that means to RC users and what they can do to continue using 'Selenium'. Probably should also be on the google code home page and in the README.

[Ross Patterson]

[Luke Inman-Semerau]

/me never learned to read!

[Patrick Lightbody]

I think in conjunction with deprecating RC, we should also update IDE to remove user extensions. That way we still maintain a clear path from IDE -> WebDriver.

On Jan 29, 2013, at 9:08 AM, Ross Patterson <rpatt...@parature.com> wrote:

<image001.png>

[Bill Ross]

FWIW I'm using RC for webdriver tests because it seems more stable than
launching multiple browsers from the test VM. I.e. I remote to the local
host without a grid. Not sure what I'll do when RC is discontinued;
perhaps just will have to run more retry iterations. I'll also need to
figure out how to launch the test VM from Jenkins with Xvfb configured.

Not a fan of the RC demise.

Bill

[Adam Goucher]

Can you clarify 'it seems more stable' ?

Also, if you use the Remote WebDriver I suspect your workflow wouldn't
change; just the API calls you make.

-adam

[Luke Inman-Semerau]

In this case RC is referring to the "Selenium" class and not to the standalone server. So if you are using WebDriver and RemoteWebDriver that is going to be (always) supported. That includes Grid2 (when you do -role hub)

-Luke

[Bill Ross]

Adam Goucher <ad...@goucher.ca> wrote:

> Can you clarify 'it seems more stable' ?

Fewer transient errors that go away on retry of the test. E.g. in
chrome, spurious 'your click would land on this other object' with
html of something adjacent to what I have specified.

> Also, if you use the Remote WebDriver I suspect your workflow wouldn't
> change; just the API calls you make.

I'm using webdriver API, so it sounds like Remote Webdriver is what I
want; it turns out to be what I thought RC is, e.g. to launch it I do
what I'm already doing:

$ java -jar selenium-server-standalone-{VERSION}.jar

Sorry, I thought that was RC.

Bill

[Jason Leyba]

On Tue, Jan 29, 2013 at 5:46 PM, Bill Ross <ro...@cgl.ucsf.edu> wrote:

Adam Goucher <ad...@goucher.ca> wrote:

> Can you clarify 'it seems more stable' ?

Fewer transient errors that go away on retry of the test. E.g. in
chrome, spurious 'your click would land on this other object' with
html of something adjacent to what I have specified.

> Also, if you use the Remote WebDriver I suspect your workflow wouldn't
> change; just the API calls you make.

I'm using webdriver API, so it sounds like Remote Webdriver is what I
want; it turns out to be what I thought RC is, e.g. to launch it I do
what I'm already doing:

$ java -jar selenium-server-standalone-{VERSION}.jar

Sorry, I thought that was RC.

That server contains end points for SeleniumRC and WebDriver.  In your code, are you using the Selenium or WebDriver API?

[Bill Ross]

Jason Leyba <jml...@gmail.com> wrote:

> On Tue, Jan 29, 2013 at 5:46 PM, Bill Ross <ro...@cgl.ucsf.edu> wrote:
>
> > Adam Goucher <ad...@goucher.ca> wrote:
> >
> > > Can you clarify 'it seems more stable' ?
> >
> > Fewer transient errors that go away on retry of the test. E.g. in
> > chrome, spurious 'your click would land on this other object' with
> > html of something adjacent to what I have specified.
> >
> > > Also, if you use the Remote WebDriver I suspect your workflow wouldn't
> > > change; just the API calls you make.
> >
> > I'm using webdriver API, so it sounds like Remote Webdriver is what I
> > want; it turns out to be what I thought RC is, e.g. to launch it I do
> > what I'm already doing:
> >
> > $ java -jar selenium-server-standalone-{VERSION}.jar
> >
> > Sorry, I thought that was RC.
> >
>
> That server contains end points for SeleniumRC and WebDriver. In your
> code, are you using the Selenium or WebDriver API?

Webdriver/PageFactory.

Bill

[Simon Stewart]

Inline. Adam beat me to it when he asked about stability :)

On Wed, Jan 30, 2013 at 1:46 AM, Bill Ross <ro...@cgl.ucsf.edu> wrote:

Adam Goucher <ad...@goucher.ca> wrote:

> Can you clarify 'it seems more stable' ?

Fewer transient errors that go away on retry of the test. E.g. in
chrome, spurious 'your click would land on this other object' with
html of something adjacent to what I have specified.

In Selenium RC, this was because it did less assiduous checks on whether or not the thing being clicked was actually clickable. When using the WebDriver API, flakiness like this is often caused by race conditions, such as the element being present on the DOM, but the CSS not having finished loading yet when you call "findElement", but everything sometimes being done when you call "click": sometimes you win that race, and the element is ready, and sometimes you lose it. 

If things improve as you introduce a network between the test and the browser, then my "it's a race" meter starts pinging wildly. The network has introduced additional latency, which means that the race is more often won in the direction that would take the most time.

Now, that's a classic politician's answer as it does nothing to actually fix your problem.

 

> Also, if you use the Remote WebDriver I suspect your workflow wouldn't
> change; just the API calls you make.

I'm using webdriver API, so it sounds like Remote Webdriver is what I
want; it turns out to be what I thought RC is, e.g. to launch it I do
what I'm already doing:

$ java -jar selenium-server-standalone-{VERSION}.jar

Sorry, I thought that was RC.

:) RC is stuff off the Selenium interface. But "RC" is short for "Remote Control", so there's plenty of scope to get confused. *sigh* The naming on this project.... :)

Simon

[Simon Stewart]

I'm not sure we want to take away capabilities from existing products: as was pointed out to me a long time ago, people who use extensions tend to rely on them. IDE users should be encouraged to migrate to Builder, once we manage to sort that out. We should definitely make sure that the path from Builder -> WebDriver is as smooth as silk. 

In my mind, there are two reasons for bumping the major version number to 3.0: deprecating a widely used API (RC) and introducing a major new product that sits in the same nice as an existing one (Builder)

Simon

[Patrick Lightbody]

Then perhaps we don't remove the ability but we surround them with a big fat UI that says user extensions only work with RC and RC is deprecated. I really believe we need to make sure there is parity between the two product lines in Selenium.

[BillR]

Inline.

On Wednesday, January 30, 2013 1:12:00 AM UTC-8, Simon Stewart wrote:

Inline. Adam beat me to it when he asked about stability :)

On Wed, Jan 30, 2013 at 1:46 AM, Bill Ross <ro...@cgl.ucsf.edu> wrote:

Adam Goucher <ad...@goucher.ca> wrote:

> Can you clarify 'it seems more stable' ?

Fewer transient errors that go away on retry of the test. E.g. in
chrome, spurious 'your click would land on this other object' with
html of something adjacent to what I have specified.

In Selenium RC, this was because it did less assiduous checks on whether or not the thing being clicked was actually clickable. When using the WebDriver API, flakiness like this is often caused by race conditions, such as the element being present on the DOM, but the CSS not having finished loading yet when you call "findElement", but everything sometimes being done when you call "click": sometimes you win that race, and the element is ready, and sometimes you lose it. 

 

I don't think it's a loading issue, since it happens some time after page load.

If things improve as you introduce a network between the test and the browser, then my "it's a race" meter starts pinging wildly. The network has introduced additional latency, which means that the race is more often won in the direction that would take the most time.

Good thinking. The reason I was thinking of was that more threads in the test VM could lead to synchronization issues. E.g. a tightly controlled news distribution client/server system* I wrote for java 1.4 showed sync issues when threads got past 50. I am running up to 15 TestNG threads, and thread id's of the test runners go up into the 40's.

* Since it was financial news and distribution to news bureaus needed to be fair, I was shooting for a 50-100ms spread between the first and last news agency to receive.

Bill

Bill

> >>> email to selenium-developers+unsub...@googlegroups.com.

> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>
> >>>
> >>>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

> >> To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
>
> --
> You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

[Simon Stewart]

Agreed about unifying the products. A warning seems best for now.

Simon

[Simon Stewart]

On Wed, Jan 30, 2013 at 7:03 PM, BillR <ro...@cgl.ucsf.edu> wrote:

Inline.

On Wednesday, January 30, 2013 1:12:00 AM UTC-8, Simon Stewart wrote:

Inline. Adam beat me to it when he asked about stability :)

On Wed, Jan 30, 2013 at 1:46 AM, Bill Ross <ro...@cgl.ucsf.edu> wrote:

Adam Goucher <ad...@goucher.ca> wrote:

> Can you clarify 'it seems more stable' ?

Fewer transient errors that go away on retry of the test. E.g. in
chrome, spurious 'your click would land on this other object' with
html of something adjacent to what I have specified.

In Selenium RC, this was because it did less assiduous checks on whether or not the thing being clicked was actually clickable. When using the WebDriver API, flakiness like this is often caused by race conditions, such as the element being present on the DOM, but the CSS not having finished loading yet when you call "findElement", but everything sometimes being done when you call "click": sometimes you win that race, and the element is ready, and sometimes you lose it. 

 

I don't think it's a loading issue, since it happens some time after page load.

My finger of suspicion turns to point at long running Javascript functions or AJAX calls. :) It might be worth hooking up a JS profiler to the page to see whether there's something that stands out.

 

If things improve as you introduce a network between the test and the browser, then my "it's a race" meter starts pinging wildly. The network has introduced additional latency, which means that the race is more often won in the direction that would take the most time.

Good thinking. The reason I was thinking of was that more threads in the test VM could lead to synchronization issues. E.g. a tightly controlled news distribution client/server system* I wrote for java 1.4 showed sync issues when threads got past 50. I am running up to 15 TestNG threads, and thread id's of the test runners go up into the 40's.

Umm... that's probably not good :(

Simon

 

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.