CODEWITHSUNDEEP
unit-testingintegration-testingazure-cosmosdb
RedCraig
RedCraig

Reputation: 503

unittesting with Azure DocumentDB

I'm interested in using azure's DocumentDB, but I can't see how to sensibly develop, run unittests / integration tests, or how to have our continuous integration server run against it.

AFAICS there's no way to run a local version of the docdb server, you only run against a provisioned instance of docdb in azure.

This means that:

Any advice on how people are approaching this with docdb would be much appreciated.

Upvotes: 3

Views: 3193

Answers (2)

Stef Heyenrath
Stef Heyenrath

Reputation: 9830

A local version from a DocumentDB is now available : https://learn.microsoft.com/en-us/azure/documentdb/documentdb-nosql-local-emulator

Upvotes: 4

Larry Maccherone
Larry Maccherone

Reputation: 9523

You are correct that there is no version of DocumentDB that you run on your own computers. So, I write unit tests for all stored procedures (sprocs) using documentdb-mock (runs client side on node.js). I do test first design (TDD) with this client side testing which has no requirement for connecting to Azure, but it only tests sprocs.

I run a number of other tests on the live Azure platform. In addition to the client-side tests, I test sprocs live with a real documentdb collection. I also test all client-side SDK code (only used for reads as I do all writes in sprocs) on the live system.

I used to have a single collection per developer for live testing but the fact each test can't guarantee the state of the database meant that some tests failed intermittently, so I switched to creating and deleting a database and collection for each test. It's slightly slower but not as slow as you would expect. I use node-unit and below is my setup and tear down code. Some points about this code:

  • I preload all sprocs every time since I use sprocs for all writes. I only use the client-side SDK for reads. You could skip this if you don't use sprocs.

  • I am using the documentdb-utils WrappedClient because it provides some added functionality (429 retry, better async API, etc.). It's a drop in replacement for the standard library (although it does not yet support partitioned collections) but you don't need to use it for the example code below to work.

  • The delay in the tear down was added to fix some intermittent failures that occurred when the collection was removed but some operations were still pending.

Each test file looks like this:

path = require('path')
{DocumentClient} = require('documentdb')
async = require('async')
{WrappedClient, loadSprocs, getLinkArray, getLink} = require('documentdb-utils')

client = null
wrappedClient = null
collectionLinks = null

exports.underscoreTest =

  setUp: (setUpCallback) ->
    urlConnection = process.env.DOCUMENT_DB_URL
    masterKey = process.env.DOCUMENT_DB_KEY
    auth = {masterKey}
    client = new DocumentClient(urlConnection, auth)
    wrappedClient = new WrappedClient(client)
    client.deleteDatabase('dbs/dev-test-database', () ->
      client.createDatabase({id: 'dev-test-database'}, (err, response, headers) ->
        databaseLink = response._self
        client.createCollection(databaseLink, {id: '1'}, {offerType: 'S2'}, (err, response, headers) ->
          collectionLinks = getLinkArray(['dev-test-database'], [1])
          scriptsDirectory = path.join(__dirname, '..', 'sprocs')
          spec = {scriptsDirectory, client, collectionLinks}
          loadSprocs(spec, (err, result) ->
            sprocLink = getLink(collectionLinks[0], 'createVariedDocuments')
            console.log("sprocs loaded for test")
            setUpCallback(err, result)
          )
        )
      )
    )

  test1: (test) ->
    ...
    test.done()

  test2: (test) ->
    ...
    test.done()

  ...

  tearDown: (callback) ->
    f = () ->
      client.deleteDatabase('dbs/dev-test-database', () ->
        callback()
      )
    setTimeout(f, 500)

Upvotes: 4

Related Questions