nunit-core team mailing list archive
-
nunit-core team
-
Mailing list archive
-
Message #02135
[Bug 893919] Re: DelayedConstraint fails polling properties on references which are initially null
** Description changed:
Having seen the great progress made on bug #890129, I've been using the After() constraint even more!
(Still using v2.5.10.11092)
I noticed a quirk with how (properties of) objects which are initially
null are polled.
An example:
- string statusString = null; // object starts off as null reference
+ string statusString = null; // object starts off as null
- var worker = new BackgroundWorker();
- worker.RunWorkerCompleted += delegate { statusString = "finished"; /* object non-null after work */ };
- worker.DoWork += delegate { Thread.Sleep(TimeSpan.FromSeconds(1)); /* simulate work */ };
- worker.RunWorkerAsync();
+ var worker = new BackgroundWorker();
+ worker.RunWorkerCompleted += delegate { statusString = "finished"; /* object non-null after work */ };
+ worker.DoWork += delegate { Thread.Sleep(TimeSpan.FromSeconds(1)); /* simulate work */ };
+ worker.RunWorkerAsync();
- Assert.That(() => statusString, Has.Length.GreaterThan(0).After(3000, 100));
+ Assert.That(() => statusString, Has.Length.GreaterThan(0).After(3000, 100));
The assert will fail after its first poll, reporting:
System.ArgumentNullException : Value cannot be null.
Parameter name: actual
I assume this is because the 'statusString' object is null, so fetching the 'Length' property causes a ArgumentNullException.
However, I'd expect that the test would at least continue to try to poll even if the value is initially null, in case it gets initialised before the timeout.
A few simple workarounds exist:
Adding a prior null check to the constraint:
- Assert.That(() => statusString, Is.Not.Null.With.Length.GreaterThan(0).After(5000, 100));
+ Assert.That(() => statusString, Is.Not.Null.With.Length.GreaterThan(0).After(3000, 100));
Or adding another separate DelayedConstraint before the Assert which checks for non-null, like this:
- Assert.That(() => statusString, Is.Not.Null.After(5000, 100));
- Assert.That(() => statusString, Has.Length.GreaterThan(0).After(5000, 100));
+ Assert.That(() => statusString, Is.Not.Null.After(3000, 100));
+ Assert.That(() => statusString, Has.Length.GreaterThan(0).After(3000, 100));
Perhaps that is because each constraint must pass or timeout before the
next is run. The documentation doesn't specify whether each 'After'
assert is run on a separate thread or whether earlier ones block.
--
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/893919
Title:
DelayedConstraint fails polling properties on references which are
initially null
Status in NUnit V2 Test Framework:
New
Bug description:
Having seen the great progress made on bug #890129, I've been using the After() constraint even more!
(Still using v2.5.10.11092)
I noticed a quirk with how (properties of) objects which are initially
null are polled.
An example:
string statusString = null; // object starts off as null
var worker = new BackgroundWorker();
worker.RunWorkerCompleted += delegate { statusString = "finished"; /* object non-null after work */ };
worker.DoWork += delegate { Thread.Sleep(TimeSpan.FromSeconds(1)); /* simulate work */ };
worker.RunWorkerAsync();
Assert.That(() => statusString, Has.Length.GreaterThan(0).After(3000, 100));
The assert will fail after its first poll, reporting:
System.ArgumentNullException : Value cannot be null.
Parameter name: actual
I assume this is because the 'statusString' object is null, so fetching the 'Length' property causes a ArgumentNullException.
However, I'd expect that the test would at least continue to try to poll even if the value is initially null, in case it gets initialised before the timeout.
A few simple workarounds exist:
Adding a prior null check to the constraint:
Assert.That(() => statusString, Is.Not.Null.With.Length.GreaterThan(0).After(3000, 100));
Or adding another separate DelayedConstraint before the Assert which checks for non-null, like this:
Assert.That(() => statusString, Is.Not.Null.After(3000, 100));
Assert.That(() => statusString, Has.Length.GreaterThan(0).After(3000, 100));
Perhaps that is because each constraint must pass or timeout before
the next is run. The documentation doesn't specify whether each
'After' assert is run on a separate thread or whether earlier ones
block.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nunitv2/+bug/893919/+subscriptions
References