a lunch conversation with @minrk and @takluyver lead me to just make a
popup and have it be closed, instead of having to reorder the test suite
so that this test always runs last. Now it doesn't matter what order the
test suite runs in, and gives us a pattern for testing window closing
behavior should we need it elsewhere.
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.
Note: this test still sometimes fails, though I don't understand why.
Increasing the wait time to 30 seconds does not help, which leads me to
believe that there's some race condition, or that we're genuinely
dropping outputs sometimes (saved notebooks on these timeouts *do*
contain an In[] number, but don't have any outputs attached). @ellisonbg
and @minrk might now what's going on with that.
To run just this test, fire up a notebook server on port 8888 and run:
while true; do casperjs test --includes=util.js test_cases/execute_code_cell.js ; done
this method wasn't currently working, and though we should put a working
method there as a utility, it isn't strictly necessary, since the whole
directory will be deleted