couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Testsuite for HTTP api: questions
Date Mon, 15 Mar 2010 17:07:45 GMT
On Mon, Mar 15, 2010 at 12:45 PM, Lena Herrmann <lena@zeromail.org> wrote:
> Hi!
>
> I'm in the middle of writing a testsuite for the CouchDB HTTP API (to be
> precise, for couch.js and jquery.couch.js, located in share/www/script).
> After that, a documentation for this API will follow.
>
> For a lot of those methods I don't know what they do and how they work. All
> the things I can't figure out by looking at the code or google I will ask
> HERE. So be prepared for lots of mails with lots of annoying questions about
> details! :)
>
>
> You can follow my work here:
> http://github.com/lenalena/couchdb/tree/testsuite
>
> I chose to write the tests in JSpec, which is a fairly new JS testing
> framework, with a RSpec like syntax. Read more about JSpec here:
> http://jspec.info/
>
> If you want to run the testsuite, clone the project, compile and run in dev
> mode, and browse to this site: http://127.0.0.1:5984/_utils/spec/run.html
> It should work in at least Firefox >= 3.6 and Safari >= 4.0.4.
>
> All comments welcome!
>
>
> ---------------------------------
>
> Now to the first bunch of questions:
>
> * Many couch.js methods, like "save" in line 48 for example, take an
> "options" hash that goes into the request headers. What different kinds of
> options are there for the requestHeaders? I only found out about
> "X-Couch-Full-Commit". What does "X-Couch-Persist" do? Are there any more
> options?
>

I'm not sure if there's any documentation that enumerates the full
list of headers that are used. There aren't too many though. The
X-Couch-Persist in particular was invented to allow running the test
suite on a modified configuration without writing the new
configuration to disk.

> * When I test generated UUIDs, at the moment I just test them to have a
> specific length (32 chars), revisions ought to have 34 chars. Is this an
> okay approach, or is this length likely to change at some point?

UUID's should be 32 hex characters. I don't see that changing as
UUID's are defined as 16 bytes. Revisions on the other hand probably
shouldn't be introspected too much. They're meant to be an opaque
token that's used for MVCC. Relying on structure or other constraints
would violate that.

> * ensureFullCommit - this method only changes the setting on my db instance,
> correct? Can I test the db if this setting has been made? (with something
> like db.full_commit == true ...)
>
> * Was exactly does ensure_full_commit do, once set? There has to be a
> definitions somewhere out there ...

If you mean testing the JS object, then I reckon there'd be a way. I'm
not entirely sure on how you'd test whether its been taken into effect
by the server as its just telling couchdb to do an fsync before
returning success.

>
> Optional stuff:
>
> * Feedback for the spec ".save should save the document with a number as ID"
> - I stumbled upon that, I don't know if we want this or not, I think it
> would be good.

Not sure I follow. _id's are strings. Saving them as a number would be
ungood. Having the JS client auto convert to a string seems like a bad
idea.

> * If we have a method "deleteDocAttachment", what about "addDocAttachment"
> and "openDocAttachment"? For the test I had to replace those - I don't know
> if they would be needed in production too, they just seem to miss.
>

I don't follow.

>
>
> If you can help me out with links, explanations or your opinion, please do!
>
> Cheers, Lena
>
>

HTH,
Paul Davis

Mime
View raw message