On 21 Mar 2010, at 06:04, Robert Dionne wrote:
> On Mar 21, 2010, at 4:00 AM, Jan Lehnardt wrote:
>
>>
>> On 20 Mar 2010, at 20:06, Paul Davis wrote:
>>
>>> On Sat, Mar 20, 2010 at 2:31 PM, Noah Slater <nsla...@me.com> wrote:
>>>> I think faulty test case should block the release, if I am to have any
>>>> future sanity preparing releases. I don't want to delay and longer, so if
>>>> you guys are absolutely sure this is a test error and not code error, then
>>>> I
>>>> propose that the test be commented out. Our tests form a contract between
>>>> us, internally, and our users. If that contract has a bug, it should be
>>>> removed or fixed - or it simply dilutes the importance of contract. If some
>>>> one comments out the test, and we agree it is not indicative of an
>>>> important
>>>> bug, I can call the vote within hours.
>>>>
>>>
>>> I'd have to agree on this. From the point of view of a release, if a
>>> test reports a failure then it should be made to not report a failure.
>>> If that's accomplished by disabling it, then there will be a commit
>>> with a message that explains why it was disabled and etc and such on
>>> and so forth.
>>
>> I'd do that if the test was failing for me :)
>
> it's not failing for you when you run changes.js with the CLI ? Fails for me
> every time.
I don't consider the CLI tests as part of the official test suite just yet.
Cheers
Jan
--
>
> Anyway I poked at this a bit yesterday and am not 100% sure the issue is in
> the test. I tried putting a sleep in with no luck. If my understanding of the
> JS is correct, CouchDB is supposed to be synchronous so it's not timing.
>
> If someone could comment on the test itself it would be helpful. The section
> of the code that fails:
>
> // changes get all_docs style with deleted docs
> var doc = {a:1};
> db.save(doc);
> db.deleteDoc(doc);
> var req = CouchDB.request("GET",
> "/test_suite_db/_changes?filter=changes_filter/bop&style=all_docs");
> var resp = JSON.parse(req.responseText);
> TEquals(3, resp.results.length, "should return matching rows");
>
>
> seems odd to me. all_docs as I read the code will return docs with deletes
> and conflicts but in this call the filter bop will not apply to the doc {a:1}
> so I'm not sure what this delete prior to the call is about. Anyway I can
> make it fail in the debugger so perhaps I can find the root cause.
>
>
>
>
>>
>> Cheers
>> Jan
>> --
>>
>
