nunit-core team mailing list archive

[Simone Busoli <simone.busoli@xxxxxxxxx>]

Interesting one, perhaps inspecting the type of the constraint we could
figure out whether we should poll or not.
On Nov 19, 2011 10:28 AM, "Charlie Poole" <charlie@xxxxxxxxx> wrote:

> When the DelayedConstraint is used with an object (value or reference)
> it simply waits the specified amount of time before evaluating the base
> constraint and no polling takes place. When it is used with  a reference
> to an object or with a delegate, polling is used.
>
> So, the following should work as expected:
>  Assert.That(ref list, Has.Count.EqualTo(1).After(5000, 100));
>
> In the example you give, polling could effectively have been used, since
> the actual value tested is a property of the object and not the object
> itself. In other cases, this would not work, since the actual value
> argument is evaluated only once, before calling Assert.That(). A simple
> example...
>
>   var worker = new BackgroundWorker();
>   int x = 0;
>   worker.RunWorkerCompleted += delegate { x = 1; }
>   worker.DoWork += delegate { Thread.Sleep(1); }
>   worker.RunWorkerAsync();
>   Assert.That(x, Is.EqualTo(1).After(5000);
>
> The value of x used in the test is zero because x was evaluated before
> calling Assert.That().
>
> I'll give this a little more thought to determine whether NUnit can make
> a runtime distinction between those arguments where polling might make
> sense and those where it would not. Clearly, we can't make the
> distinction syntactically.
>
> Charlie
>
> --
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
> https://bugs.launchpad.net/bugs/890129
>
> Title:
>  DelayedConstraint doesn't appear to poll properties of objects
>
> Status in NUnit V2 Test Framework:
>  New
>
> Bug description:
>  Using 2.5.10.11092.
>
>  I've just been exploring the new (to me) fluent/constraints syntax,
> specifically the After() constraint and am very impressed.
>  I've already learnt not to pass by value (!), however, I thought that a
> pass-by-reference should be ok.
>
>  For example:
>           var worker = new BackgroundWorker();
>           var list = new List<int>();
>           worker.RunWorkerCompleted += delegate { list.Add(1); };
>           worker.DoWork += delegate { Thread.Sleep(1); };
>           worker.RunWorkerAsync();
>           Assert.That(list, Has.Count.EqualTo(1).After(5000, 100));
>
>  The documentation states that its "intended use is with delegates and
> references", so I'd expect the 'list' object reference to be polled, and
> after about 1 second, for the constraint to pass.
>  However, I have to wait for the full 5 seconds before the test succeeds.
>
>  The obvious work around is to convert the 'list' object to a delegate:
>           Assert.That(() => list, Has.Count.EqualTo(1).After(5000, 100));
>
>  This works fine, and still look ok (to me).
>
>  However, I wondered if this is deliberate or unavoidable behaviour or
>  just a bug...
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/890129/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~nunit-core
> Post to     : nunit-core@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nunit-core
> More help   : https://help.launchpad.net/ListHelp
>