1019210 - add a function to test if the marionette server is running

Status: RESOLVED WONTFIX

(Remote Protocol :: Marionette, defect)

Description

[Malini Das [:mdas] - Away, not checking bugmail]

the marionette client has a 'wait_for_port' method, which is useful for testing if the server is running, but AFAIK, we don't test if it can respond to start_session. We should add a function, say "check_marionette_responsive" which will do a wait_for_port() followed by a start_session() and end_session(). 

This is useful because there are times where the server is running, so wait_for_port() returns happily, but your code will break later. Also, there's a delay between when the port opens and when marionette is active, so this can help scripts interact with marionette when it is ready.

Comment 1

[Malini Das [:mdas] - Away, not checking bugmail]

I also see a bunch of products that use marionette try to implement their own checks, so instead of putting the onus on the consumer to keep code in check, this would be a standard, supported way to check if marionette is running.

Comment 2

[Malini Das [:mdas] - Away, not checking bugmail]

== Good First Bug Instructions ==

Hello Contributor!

To work on this bug, you'll need a local copy of mozilla-central to make changes and test them:

https://hg.mozilla.org/mozilla-central/

the Marionette client lives in 
<mozilla-central>/source/testing/marionette/client/marionette/

To start running tests, go into the Marionette client directory and create a virtual environment:

virtualenv my_venv

(if you do not have virtualenv, install it using `pip install virtualenv`)

Then activate it and install marionette client:

. my_venv/bin/activate
python setup.py develop

To run the test suite (to verify everything works) you can do:

python runtests.py --binary=<path to your firefox executable> tests/unit/unit-test.ini

This should start up a browser and run tests against it. The firefox executable path is an executable file within your Firefox Application named 'firefox' on Mac/Linux and 'firefox.exe' in Windows (not sure about Marionette's compatibility with Windows though!). You can stop the tests from running by doing Cmd+C or Ctrl+C.

Once you have that going, you can start coding. To start this bug, you'll need to add a function called check_marionette_responsive. You can add the function after wait_for_port, which is here: https://mxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/marionette.py?rev=798860192cb4#581. 

check_marionette_responsive() should take in an optional parameter, a timeout, so I can do check_marionette_responsive(120), and it will try to contact marionette for 120 seconds. If it is unsuccessful after the 120 seconds, it will return False. We shouldn't require this parameter, so let's use a default value of 60 seconds if the user does not pass one it.

check_marionette_responsive() should call wait_for_port() and if wait_for_port returns True, then it should call start_session(), and if that is successful, it should call delete_session(). You should wrap the start_session() call in a try/except structure, because it can throw different kinds of errors if marionette isn't ready. The exceptions it can throw are: IOError and socket.error. If these are thrown, you should wait about 2 seconds and retry calling start_session(). If you exceed the timeout, then return False. If you start_session() passes, the next step is to call delete_session(), and do that in another try/except block. In this case, a general 'except' line will do; we want to catch *all* exceptions. If you see any exception at this stage, return False. If you can delete_session() without problem, then you return True.

Comment 3

[Zac C (:zac)]

Mdas, this sounds very similar to bug 1001322 although a bit more explicit. Can you dupe the other if it is a dupe?

Also I think this is more important than a gfb, I'd like it to be fixed properly. As you state, many packages are implementing their own versions of this. We can normalise them all sooner if this is done.

Comment 4

[Malini Das [:mdas] - Away, not checking bugmail]

(In reply to Zac C (:zac) from comment #3)
> Mdas, this sounds very similar to bug 1001322 although a bit more explicit.
> Can you dupe the other if it is a dupe?
> 
> Also I think this is more important than a gfb, I'd like it to be fixed
> properly. As you state, many packages are implementing their own versions of
> this. We can normalise them all sooner if this is done.

It's not quite a dupe, though we'll continue the discussion on that bug

Comment 5

[Malini Das [:mdas] - Away, not checking bugmail]

== Good First Bug Instructions ==

Hello Contributor!

To work on this bug, you'll need a local copy of mozilla-central to make changes and test them:

https://hg.mozilla.org/mozilla-central/

the Marionette client lives in 
<mozilla-central>/source/testing/marionette/client/marionette/

To start running tests, go into the Marionette client directory and create a virtual environment:

virtualenv my_venv

(if you do not have virtualenv, install it using `pip install virtualenv`)

Then activate it and install marionette client:

. my_venv/bin/activate
python setup.py develop

To run the test suite (to verify everything works) you can do:

python runtests.py --binary=<path to your firefox executable> tests/unit/unit-test.ini

This should start up a browser and run tests against it. The firefox executable path is an executable file within your Firefox Application named 'firefox' on Mac/Linux and 'firefox.exe' in Windows (not sure about Marionette's compatibility with Windows though!). You can stop the tests from running by doing Cmd+C or Ctrl+C.

Once you have that going, you can start coding. To start this bug, you'll need to add a function called check_marionette_responsive. You can add the function after wait_for_port, which is here: https://mxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/marionette.py?rev=798860192cb4#581. 

check_marionette_responsive() should take in an optional parameter, a timeout, so I can do check_marionette_responsive(120), and it will try to contact marionette for 120 seconds. If it is unsuccessful after the 120 seconds, it will return False. We shouldn't require this parameter, so let's use a default value of 60 seconds if the user does not pass one it.

check_marionette_responsive() should call wait_for_port() and if wait_for_port returns True, then it should call start_session(), and if that is successful, it should call delete_session(). If wait_for_port() is unsuccessful, throw an Exception about being unable to connect to the port. If you are successful, then call start_session(). You should wrap the start_session() call in a try/except structure, because it can throw different kinds of errors if marionette isn't ready. The exceptions it can throw are: IOError and socket.error. If these are thrown, you should wait about 2 seconds and retry calling start_session(). If you exceed the timeout, then throw an Exception about being unable to start a session. If you start_session() passes, the next step is to call delete_session(), and do that in another try/except block. In this case, a general 'except' line will do; we want to catch *all* exceptions. If you see any exception at this stage, throw that Exception. If you can delete_session() without problem, then you return True.

Comment 6

[Malini Das [:mdas] - Away, not checking bugmail]

== Good First Bug Instructions Continued ==

To test out your code, I recommend using pdb, which will let you modify the state of your program *while* you're running it. First, you'll need to create breakpoints in your code, so in the marionette.py file, add 'import pdb', and wherever you want to create a breakpoint, add a line with 'pdb.set_trace()'

Next, you can start firefox with marionette:

<path to firefox executable> --marionette

Then do:

python
from marionette import check_marionette_responsive
check_marionette_responsive()

and if you put a breakpoint in that function, it will drop you into a pdb session where you can continue execution and throw Exceptions wherever you like, so you can test out your try/except blocks using pdb. Please drop by on IRC for more information if this is unclear.

Comment 7

[Malini Das [:mdas] - Away, not checking bugmail]

I'm removing this from good first bugs until we sort out the issues in Bug 1001322

Comment 8

[Malini Das [:mdas] - Away, not checking bugmail]

I'm going to resolve wontfix this unless we have consensus on its use. Right now, the feeling is that it is niche, and could be used incorrectly