Question

A bit of background:

I have a web application that reads from a denormalised set of documents stored in RavenDB. These documents are created and modified by event handlers. In production the application uses a standard document store which connects to a remote database via the c# API.

When I unit test the application I configure the handlers to use an in memory embedded database, create some events, and query for the expected documents. This works absolutely fine.

Writing UI tests:

I want to enable our testers to write automated UI tests using SpecFlow and Selenium. When implementing this for other applications (using SQL), the execution of the feature files would prepare a testing environment by:

  • Creating a new database in a local SQLExpress instance (by convention everyone has the same instance name on their machines)
  • Reconfigure the handlers to use the new database and raise events to create the desired state
  • Copy the web application under test into a new temporary location and reconfigure to read from the new database
  • Start the web application in IIS Express (once again everyone follows this convention)
  • Run the feature(s), blanking and rebuilding the state between each if desired
  • Stop IIS, remove the application under test, and drop the database

Now I would like to follow the same approach using Raven and am considering two approaches.

The first is to follow the exact same model as above. The issues I have here are how/where to store the databases, and how to tidy them up afterwards. The server executable could be started and stopped programmatically during setup and teardown, and the database could be removed afterwards by deleting the file. I haven't tried this but in theory it should work.

The second is to follow a similar approach but to substitute the standard document store for an embedded one (not running in memory). For this to work I need to modify the IoC (possible if using config in xml) of the web application to resolve an IDocumentStore to an EmbeddedDocumentStore. I then build up the state using the handlers as before, then dispose of the handlers' document store before starting IIS (it does not seem to be possible to run two applications at the same time that use the same embedded database unless I'm missing something).

The second approach seemed the better choice initially but I am encountering some strange behaviour whereby the documents created by the handlers is not consistent with the results returned when the web application queries it. Specifically, some child collections are populated by the handlers but are empty when returned from a query executed by the web application. To be honest I wasn't too surprised as I doubt this is the scenario in which embedded databases were intended to be used. In addition it is very difficult to view the embedded database via the management studio as I jump from one application to another.

So anyway, after that long winded description I am curious what others think of these approaches and if there is a better alternative I am missing. In addition I'm sure there are many hidden RavenDB gems that I am not aware of, so any pointers in that direction would be helpful too.

Was it helpful?

Solution

Nigel, Start/stop the raven.server programmatically. But pass the /ram flag in, which would let you run the entire thing in memory and can take care of all of the cleanup work

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top