Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notebook javascript test suite using CasperJS #4285

Merged
merged 60 commits into from Oct 23, 2013

Conversation

ivanov
Copy link
Member

@ivanov ivanov commented Sep 26, 2013

With this PR, you can just iptest js, and if casperjs is found, and the
ipython notebook dependencies are met, the test suite will run. There are
still a couple of things left to polish off, but it works.

closes #2292

  • write a test suite runner into our tools
  • start a new notebook server as part of the test run
  • don't hardcode path to notebook server
  • skip group if casper and phantomjs not found
  • eliminate 2000 ms wait time in execute code
  • informative message on timeout (likely server not started)
  • --port= command line argument when running casperjs test directly
  • no-browser flag
  • run in a temporary directory
  • xunit is a possibility for casper, integrate that in to the controller configuration
  • document how to write new tests
  • make test suite run properly when --fast flag is used (currently times out, due to slow startup, perhaps?)
  • make sure kernels actually shut down (they currently don't on failure) (optional)

@minrk's input on the following two would be great:

  • redirect stdout and stderr of the notebook server (mitigated by --log-level=0)
  • AssertionError: Request closed (mitigated by not deleting individual notebooks)
     ERROR:tornado.application:Exception in callback <functools.partial object at 0x57bdf18>
    Traceback (most recent call last):
      File "/home/pi/code/ipython-sloan/pyzmq/zmq/eventloop/minitornado/ioloop.py", line 463, in _run_callback
        callback()
      File "/home/pi/code/ipython-sloan/pyzmq/zmq/eventloop/minitornado/stack_context.py", line 331, in wrapped
        raise_exc_info(exc)
      File "/home/pi/code/ipython-sloan/pyzmq/zmq/eventloop/minitornado/stack_context.py", line 302, in wrapped
        ret = fn(*args, **kwargs)
      File "/usr/lib/python2.7/dist-packages/tornado/iostream.py", line 311, in wrapper
        callback(*args)
      File "/usr/lib/python2.7/dist-packages/tornado/httpserver.py", line 268, in _on_headers
        self.request_callback(self._request)
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 1427, in __call__
        handler._execute(transforms, *args, **kwargs)
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 1046, in _execute
        self._handle_request_exception(e)
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 1086, in _handle_request_exception
        self.send_error(500, exc_info=sys.exc_info())
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 741, in send_error
        self.finish()
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 721, in finish
        self.flush(include_footers=True)
      File "/usr/lib/python2.7/dist-packages/tornado/web.py", line 681, in flush
        self.request.write(headers + chunk, callback=callback)
      File "/usr/lib/python2.7/dist-packages/tornado/httpserver.py", line 418, in write
        self.connection.write(chunk, callback=callback)
      File "/usr/lib/python2.7/dist-packages/tornado/httpserver.py", line 183, in write
        assert self._request, "Request closed"
    AssertionError: Request closed

@minrk
Copy link
Member

minrk commented Sep 26, 2013

Hooray!

@ellisonbg
Copy link
Member

:-)

On Thu, Sep 26, 2013 at 10:07 AM, Min RK notifications@github.com wrote:

Hooray!


Reply to this email directly or view it on GitHubhttps://github.com//pull/4285#issuecomment-25185169
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

@ivanov
Copy link
Member Author

ivanov commented Sep 26, 2013

rebased on top of master

@ellisonbg
Copy link
Member

Should we close #3125 ?


The file `util.js` contains utility functions for tests,
including a hardcoded path to a running notebook server
(http://127.0.0.1:8888 by default).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should run the test suite using a notebook server on a different port than our default. Otherwise, if someone has a notebook server running already, the test suite would use it, potentially clobbering their notebooks. Pick some high random port number like 10345

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, that README was outdated, we actually grab a new port number as usual, and pass that along to the test suite

@ellisonbg
Copy link
Member

I love the look of this - I think that writing tests, with a bit more infrastructure in utils.py is going to be pretty nice. I should note that when I run the tests, I get lots of failures though. Is that expected or do you think it is a timing issue with the starting of the notebook server?

@ivanov
Copy link
Member Author

ivanov commented Sep 26, 2013

Should we close #3125 ?

There's a commit in here that will do that on merge.

@minrk minrk mentioned this pull request Sep 27, 2013
@dwyde
Copy link
Contributor

dwyde commented Sep 29, 2013

Glad to see this has been revived :-)

I just realized that the code cell execution test fails in Python 3 because of the print statement...

casper.notebook_test(function () {
this.evaluate(function () {
var cell = IPython.notebook.get_cell(0);
cell.set_text('a=10; print a');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

print(a)

@pablooliveira
Copy link
Contributor

First, this is really nice, I hope it will be merged soon :)

I tried writing some new js tests. When tests fail, I get sometimes (but not always) the following traceback:

2013-10-09 09:04:02.153 [tornado.application] ERROR | Uncaught exception, closing connection.
Traceback (most recent call last):
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/iostream.py", line 341, in wrapper
    callback(*args)
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/stack_context.py", line 331, in wrapped
    raise_exc_info(exc)
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/stack_context.py", line 302, in wrapped
    ret = fn(*args, **kwargs)
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/websocket.py", line 450, in _on_end_delimiter
    self._receive_message()
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/websocket.py", line 434, in _receive_message
    self.stream.read_bytes(1, self._on_frame_type)
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/iostream.py", line 168, in read_bytes
    self._try_inline_read()
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/iostream.py", line 418, in _try_inline_read
    self._check_closed()
  File "/home/poliveira/ipython/env/local/lib/python2.7/site-packages/tornado/iostream.py", line 580, in _check_closed
    raise StreamClosedError("Stream is closed")
StreamClosedError: Stream is closed
ERROR:tornado.application:Uncaught exception, closing connection.

Nevertheless, the number of passed/failed tests is correct, so maybe this is not that important.

ivanov added a commit to ivanov/ipython that referenced this pull request Oct 9, 2013
@ivanov
Copy link
Member Author

ivanov commented Oct 14, 2013

@pablooliveira I'm also seeing these messages, trying to track down what's causing them, but you're definitely not alone

@ivanov
Copy link
Member Author

ivanov commented Oct 19, 2013

ok, I've added some more tests here, including testing of interrupts via "mouse click" and via keyboard shortcuts. This took a while, since the combination of JavaScript, JQuery, CasperJS and phantomJS is a bit tricky to figure out who should be doing what... The uncaught exception stuff that @pablooliveira and I were seeing earlier are also gone now, and notebook kernels shutdown properly at the end of the tests.

@sychan
Copy link
Contributor

sychan commented Oct 22, 2013

Paul - do you have any sense of whether it would be workable to backport the diffs to the 1.x branch? I tried a test merge of the 1.x branch against this branch and of course there were deltas all over the place. When we tried to run our notebook against IPython master branch the other week all kinds of things were unhappy so I don't think we can use the master branch as-is.

@takluyver
Copy link
Member

I'm pretty sure this is not going to be backported to 1.x - that branch is only getting bugfixes.

@sychan
Copy link
Contributor

sychan commented Oct 22, 2013

I'm willing to do the work myself, if Paul thinks that it is not too onerous. Our project needs front end testing over the next couple of months - but if it makes more sense to just code up a separate, lightweight CasperJS based test setup until until 2.0 gets into a release candidate form, I can go that route as well.

@sychan
Copy link
Contributor

sychan commented Oct 22, 2013

I tried the quick and dirty test of just running the casperjs tests directly against a 1.x server, and they seem to function standalone (though about half of the tests seem to fail - but I can work with that), so I guess that seems adequate for now.

@ivanov
Copy link
Member Author

ivanov commented Oct 23, 2013

@sychan yeah, it shouldn't be too bad to get this working against 1.x, Steve. After all, this is a continuation of work that was sitting in a PR pre 1.0 (7 months ago).

@takluyver
Copy link
Member

Merging this now, people can keep adding tests in new branches.

@takluyver
Copy link
Member

(actually, it needs a rebase)

this line causes noise in the test suite, but if we just ignore it,
we'll never get to the bottom of it. It seems to only happen when
running 'iptest js', and *not* when running the 'casperjs test' command
directly, with a notebookserver that was launched manually.
the PPA we use on Travis CI doesn't have CasperJS 1.1.0-DEV yet, so
we're better off not using it for now.
takluyver added a commit that referenced this pull request Oct 23, 2013
Notebook javascript test suite using CasperJS
@takluyver takluyver merged commit 459371d into ipython:master Oct 23, 2013
brettin pushed a commit to kbase/narrative that referenced this pull request Jun 12, 2014
…so that they would run with the current 1.x branch. Currently passes the basic tests
mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
Notebook javascript test suite using CasperJS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Client side tests for the notebook
7 participants