Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,548

filter by tags archive

When unit testing a server, why not USE the server?

time to read 2 min | 288 words

One of the interesting aspects of build RavenDB was that it opened up my mind to the way we can use the very nature of the server to open up additional information about the server operations.

One thing that I noticed recently is that if I need to debug a test for RavenDB, I often need to stop the current thread (the Test thread) and then literally go to the server test instance and look at what is actually going on in there.

The fun part is that this is really nice, because I can go an inspect the running test instance, see what is going on, modify things to see how they affect the behavior, etc. The only problem is that this is actually quite complex to setup manually (stop on debugger, freeze the appropriate thread, resume run, inspect server – modify stuff there, stop on debugger, thaw thread, continue run, etc).

What occurred to me, however, is that I can codify this behavior, and end up with this:


This method will only operate while a debugger is attached, but it is going to save me a long time.  Once I am done, I need to delete the marker document:


This is especially important if you are running in and in memory mode, since the moment the test is over, the database is completely wiped out.



It's a good idea, but is it UNIT testing?

Ayende Rahien


It is when you are writing a database server

Jimmy Zimmerman

It's Functional Testing. They just use the same technical frameworks but have a different perspective and victory conditions associated with them. As a trite analogy:

Relativistic physics and quantum mechanics use the same 'framework', mathmatics, but they have a very different perspective of the subject (the very big and heavy vs the very small and light). It's all about perspective not the tooling...

Regardless, this is a FANTASTIC pattern to codify the human interaction of the test harness! Talk about making intentions explicit in your code (and yes test code is STILL code so all those same design goals hold true). Cheers!

Comment preview

Comments have been closed on this topic.


  1. The low level interview question - 7 hours from now
  2. The worker pattern - 3 days from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats