I recently wrote a testsuite for CouchDB's Javascript HTTP API. Among the things I tested were the security methods. That's those that deal with authentication - like signup, login, logout and so on. The challenge was to make sure my tests wouldn't interfere with the CouchDB setup of the person running the tests.
Background
CouchDB stores the information about the database users in a special database, the authentication_db. The default authentication_db is called "_users". So this is where your user data is saved when you sign up without taking care about the details, e.g. when you use the signup method provided by the JQuery HTTP API. Read more about the ways to interact with the authentication_db in the HTTP API documentation (JQuery methods), and read more about general CouchDB security in the CouchDB Wiki or in The Definitive Guide.
How to set the authentication_db
When you e.g. create database users from within your tests, how can you make sure they don't mess up the actual authentication_db, the one the unsuspecting user might use in production?
CouchDB is a database that I quite like. In fact, I haven't done much else this winter, as the programming part of my thesis involved diving into many of CouchDB's features. I had just finished my little program and was desperately looking for an excuse not to start writing the thesis. Mercifully Jan from Couchio came along and asked if I wouldn't like to write a testsuite for CouchDB's Javascript HTTP API, and the documentation with it. I wanted!
What is this HTTP API?
If you have worked with CouchDB from a Javascript program before (eg Sammy.js is a good companion for a simple web application), you have probably used the methods a file named couch.js provides. With this interface you can easily access the most common CouchDB functionality without having to handle the XMLHttpRequest yourself. It allows you to create a "database object" and then perform things on this object, for example save or delete documents: