couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wendall Cada <>
Subject Re: Javascript Test Suite
Date Mon, 01 Apr 2013 23:53:28 GMT
On 03/29/2013 11:19 AM, Paul Davis wrote:
> Awesome work Wendall.
> For #2 I did some work during the merge stuff to try and make the
> server restarts more robust. Its a pretty small commit but definitely
> seemed to help.
Thanks Paul! This was on my list and pretty much what I was thinking.

> On Thu, Mar 28, 2013 at 12:22 PM, Wendall Cada <> wrote:
>> On 03/27/2013 02:05 PM, Wendall Cada wrote:
>>> In 1.3.0, there is a new part of the test suite to run the javascript
>>> tests from the command line. I'm running into various issues on different
>>> hardware/OS configurations. Mostly, tests hanging or timing out and failing.
>>> These are really hard to troubleshoot, as they all pass just fine if run
>>> individually.
>>> What I'm experimenting with today is rewriting how the tests are
>>> implemented to be run one at a time from a loop in bash, versus a loop in
>>> javascript. I think the failures I'm running into are improper
>>> setup/teardown. There may be an issue with rapid delete and adding a db, or
>>> rapidly starting and stopping couchdb, but I think this is not what's
>>> happening in my failures.
>>> The nature of spidermonkey doesn't allow for spawning threads, or
>>> sandboxing, etc, so it's hard looking at the test suite to see how I can
>>> improve running all tests. I think it's far better to have the setup spawn a
>>> new interpreter for each test. Tear down will kill the interpreter.
>>> Wendall
>> An update here. I spent some time with this yesterday.
>> There are two problems here I'd like to address.
>> 1. When running `make check`, the entire javascript test suite runs in a
>> single interpreter thread. This means that if there are any broken tests,
>> then entire suite bails, as it can crash the interpreter. As I said, to
>> address this, I simply want to refactor the test suite to spawn a new
>> interpreter thread for every test. This is working well for me with my quick
>> work yesterday, and allows me to put a small delay in between tests to
>> ensure proper tear down from the previous test.
>> 2. Some of the tests are written in a way that can cause a race condition in
>> the test itself. Quite a few places exist in the current javascript tests
>> where infinite loops can get generated. I simply want to re-factor several
>> of these tests to work as expected and avoid the race conditions entirely.
>> One additional thought I had was to mimic the output of the etap tests a bit
>> more. Show the entire path to the test file being run, with a status at the
>> end of the line. Change the individual test run to include the full path to
>> the test to be run. Additionally, the run scripts would benefit from having
>> some help output. I'm in the process of gathering notes for the
>> documentation as well.
>> My thinking is that if the test suites are similar, it will be helpful to
>> new developers in troubleshooting issues.
>> If nobody has any objections, I'd like to get started on this work. I have a
>> local branch in progress for this already, but it's mostly just a scratch
>> space for testing so far.
>> Wendall

View raw message