Question

I’m trying to debug a unit test that fails about 30% of the time. It seems to be some kind of timing issue, because unfortunately, it never fails when I have a breakpoint in the code.

So, I set a conditional breakpoint at the problematic assertion that fires when the assertion is going to be false. As expected, I hit the breakpoint about 1/3 of the time. However, when I actually inspect the value of the expression, everything looks okay. And, sure enough, if I hit continue, the test succeeds.

Can anyone help me understand why this might be the case? If another thread were modifying the value, wouldn’t the thread stop when I hit my breakpoint? Or is it possible that something like this is happening:

1. Check condition… evaluate to true
2. Another thread modifies variable
3. Break

I’m really not looking for specific solutions to my problem (there’s too much code to reasonably post, or expect anyone to trudge through). I’m just looking for general input on how conditional breakpoints work, and the reasons such a thing might happen.

Note: I’m using Visual Studio 2012 (and .NET 4.0 C# if it matters).

Also Note:

Here is the assertion that is failing:

foreach (KeyValuePair<Guid, DateTime> time in state.Times) {
    Assert.IsTrue(time.Value > DateTime.Now.AddYears(2) && time.Value <= DateTime.Now.AddYears(3));
}

Answer 1

Do you happen to have any get {}s with side affects? It’s possible that while observing the state of the object, you’ve change the state of the object.

For example :

class A {
    int one = 0;

    int two { 
        get { 
            one = 1; 
            return 2; 
        } 
    }
}

Now when you assert A.one == 1, it fails. If you look at it, you’ll see that two == 2 and one == 1. When you hit retry again, the assertion passes because you’ve change A.one.

EDIT :

Seeing your code, DateTime.Now changes everytime you call it. You don’t think that could be it?