Over a million developers have joined DZone.

Debugging a Failing Unit-Test Which Interacts with RavenDB

DZone's Guide to

Debugging a Failing Unit-Test Which Interacts with RavenDB

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

This week I'm working with Particular Software of NServiceBus fame. There's a shiny new platform for designing, managing and debugging distributed systems coming up, and while doing some work on it I hit the following failing test. The documentStore is an EmbeddableDocumentStore which was properly initialized, and the index used was registered properly. Nevertheless, the first Assert is failing. Can you figure out what's wrong?

    public void Order_by_critical_time()
        session.Store(new ProcessedMessage
            Id = "1",
            MessageMetadata = new Dictionary<string, object> { { "CriticalTime", TimeSpan.FromSeconds(10).Milliseconds} }

        session.Store(new ProcessedMessage
            Id = "2",
            MessageMetadata = new Dictionary<string, object> { { "CriticalTime", TimeSpan.FromSeconds(20).Milliseconds} }

        var firstByCriticalTime = session.Query<MessagesViewIndex.SortAndFilterOptions, MessagesViewIndex>()
              .OrderBy(x => x.CriticalTime)
              .Customize(x => x.WaitForNonStaleResults())
        Assert.AreEqual("1", firstByCriticalTime.Id);

        var firstByCriticalTimeDesc = session.Query<MessagesViewIndex.SortAndFilterOptions, MessagesViewIndex>()
              .OrderByDescending(x => x.CriticalTime)
        Assert.AreEqual("2", firstByCriticalTimeDesc.Id);

I wasn't able to figure out what was going wrong. Results were just coming back out of order, and I couldn't tell if it was something bad with the index, or the documents inserted by the test were faulty?

Luckily, there is an easy way out - and it's exactly what I used. You can suspend a unit-test while running it in Debug by calling WaitForUserToContinueTheTest(documentStore); - this method as well as some other helper methods are available in this nuget package, or in the source form here. Just add it to your unit testing classes and call it when needed.

This method is super useful - it will suspend the test and open up the management studio of the embedded database instance used by the test, so you could go through it and look at the documents it has, the index definitions, execute queries against it and so on.

So I added those 2 lines to my test, just before the first query:


And executed the test again. Now the Management Studio opened up, and the culprit was immediately visible by having a quick look at the documents in the document store - the CriticalTime property was 0 on both documents, not what I was expecting. I've spent too much time in the Java land apparently, and forgot that I had to use the Ticks property of the TimeSpan class to get the actual time value as a long.

Making this change made the test green again, and off I went to working on the next feature. I sure have saved myself quite a lot of time and hair.

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}