DelayedConstraint fails polling properties on references which are initially null

Although the 2.6 beta 2 has a fix for use of polling with After, this particular issue hasn't come up before.

Although what you propose makes sense, it's not entirely clear how we can implement it because it's entirely possible to be testing for a null value...

   Assert.That(() => statusString, Is.Null.After(3000,100));

A silly example, but one we have to deal with.

One approach would be for DelayedConstraint to analyze all following constraints to determine if a null reference will cause a problem. This could be messy and violates the independence of composed constraints. Another might be to catch the null reference exception and ignore it during polling.

I think your first workaround is better, since it doesn't depend on knowledge of NUnit's internals. The After constraint is in fact run on a separate thread, but the main thread blocks until it is complete.

Charlie

BTW, it would be good if you could test out the behavior of your examples on the 2.6 beta, since there will be no further 2.5 releases.

Charlie

Thanks for the quick response.

I think your 'null test' example certainly makes good sense. I'm writing tests to check whether an event handler is called with the correct arguments from another thread within a specific time.
In some cases I also want to make sure it's *not* called, in which case the handler arguments should remain null - so I have plenty of Is.Null.After(...) tests too.

So the behaviour of that should not change. However, in the example I gave earlier, the problem isn't the object being null/not null, it's that polling properties of the object will always fail on the first poll in the case where the object is null.

Further similar problems can be found using the following examples:
    Assert.That(() => statusString.Length, Is.GreaterThan(0).After(3000, 100));
    Assert.That(() => statusString, Has.Property("Length").GreaterThan(0).After(3000, 100));

This problem has also lead to timing issues where the test passes if the event which initialises the object occurs early enough, otherwise it will fail (I only found the problem when I ran all the tests in the fixture, rather than each test individually).

Your suggestion of catching and ignoring the null reference exception seems like the right solution to me.

However, I thought of a case where this may lead to a problem where exceptions are expected after a delay, eg:
    Assert.That(() => statusString.Count, Throws.TypeOf<NullReferenceException>.After(3000, 100));

Perhaps the null reference exception should only be thrown when using a 'Throws' constraint?

(Apologies for syntax errors etc, I don't have access to Visual Studio presently)