We Keep Coding

Evaluate NUnit assertion after a delay

I'm trying to write a unit test with NUnit for a method that could take anywhere from 1 to 3 seconds to complete. In order to valid the test all I need to do is check if a List<string> entries has been incremented in that 1 to 3 second span.
My current solution is to use a Thread.Sleep():
1. int currentEntries = entries.count;
2. Call methodA()
3. Thread.Sleep(3000);
4. int updatedEntries = entries.count;
5. Assert.That(updatedEntries, Is.EqualTo(currentEntries+1));
This solution always takes at least 3 seconds, even when methodA() finishes faster.
I have tried using NUnits Delay constraint:
Assert.That(entries.Count, Is.EqualTo(currentEntries+1).After(3).Seconds.PollEvery(250).MilliSeconds);
This would have been ideal, since it supports polling. But the After constraint is still evaluated instantly instead of after 3 seconds, as discussed here.
Is there a better solution to this issue?

Your call to Assert.That has an actual argument, which is evaluated immediately before the method is called. The value of entries.Count is taken and the resulting integer value is copied as the method argument. Within the method, we are dealing with a constant.
When the constraint is re-evaluated every 250 milliseconds, it is done each time against that same copied constant, which of course never changes.
When you use a delayed constraint, with or without polling, the actual argument has to be in the form of a delegate, a lambda or a reference to a field. The following simple modification should make it work.
Assert.That (() => entries.Count, Is.EqualTo(currentEntries+1).After(3).Seconds.PollEvery(250).MilliSeconds);
Alternatively, this should work as well
Assert.That (entries, Has.Count.EqualTo(currentEntries+1).After(3).Seconds.PollEvery(250).Milliseconds);
because the property is evaluated each time we poll.

Charlie's answer nails your actual problem (as his answers always do). However, I'd strongly recommend against having tests which depend upon delays. If your test fails, how will you know whether the problem was that you just didn't wait long enough.
Also, if this is part of an automated test suite, the elapsed time for executing all the tests will become extremely expensive as you add more tests like this.
Good tests are deterministic. For example, see Martin Fowler's Eradicating Non-Determinism in Tests, which includes the phrase:
Never use bare sleeps to wait for asynchonous responses: use a callback or polling.
My suggestion would be to refactor your code so that the functionality is separated from the threading, and test the functionality, not the threading part.
Once this separation is achieved, the code which calls the functionality on a thread can be given a Mock, and you can simply verify that the Mock was called, since you have separately tested that it behaves correctly, although that still requires polling...so:
If you encapsulate the code which launches the separate thread, then in your test, provide a mocked thread launcher which actually executes the code synchronously. So as soon as the code being tested has completed, you can make the assertion, without waiting.

Best way to delay execution

Let's say I have a method that I run in a separate thread via Task.Factory.StartNew().
This method reports so many progress (IProgress) that it freezes my GUI.
I know that simply reducing the number of reports would be a solution, like reporting only 1 out of 10 but in my case, I really want to get all reports and display them in my GUI.
My first idea was to queue all reports and treat them one by one, pausing a little bit between each of them.
Firstly: Is it a good option?
Secondly: How to implement that? Using a timer or using some kind of Task.Delay()?
UPDATE:
I'll try to explain better. The progress sent to the GUI consists of geocoordinates that I display on a map. Displaying each progress one after another provide some kind of animation on the map. That's why I don't want to skip any of them.
In fact, I don't mind if the method that I execute in another thread finishes way before the animation. All I want, is to be sure that all points have been displayed for at least a certain amount of time (let's say 200 ms).

Sounds like the whole point of having the process run in a separate thread is wasted if this is the result. As such, my first recommendation would be to reduce the number of updates if possible.
If that is out of the question, perhaps you could revise the data you are sending as part of each update. How large, and how complex is the object or data-structure used for reporting? Can performance be improved by reducing it's complexity?
Finally, you might try another approach: What if you create a third thread that just handles the reporting, and delivers it to your GUI in larger chunks? If you let your worker-thread report it's status to this reporter-thread, then let the reporter thread report back to your main GUI-thread only occasionally (e.g. every 1 in 10, as you suggest yourself above, bur then reporting 10 chunks of data at once), then you won't call on your GUI that often, yet you'll still be able to keep all the status data from the processing, and make it available in the GUI.
I don't know how viable this will be for your particular situation, but it might be worth an experiment or two?

I have many concerns regarding your solution, but I can't say for sure which one can be a problem without code samples.
First of all, Stephen Cleary in his StartNew is Dangerous article points out the real problem with this method with using it with default parameters:
Easy enough for the simple case, but let’s consider a more realistic example:
private void Form1_Load(object sender, EventArgs e)
{
Compute(3);
}
private void Compute(int counter)
{
// If we're done computing, just return.
if (counter == 0)
return;
var ui = TaskScheduler.FromCurrentSynchronizationContext();
Task.Factory.StartNew(() => A(counter))
.ContinueWith(t =>
{
Text = t.Result.ToString(); // Update UI with results.
// Continue working.
Compute(counter - 1);
}, ui);
}
private int A(int value)
{
return value; // CPU-intensive work.
}
...
Now, the question returns: what thread does A run on? Go ahead and walk through it; you should have enough knowledge at this point to figure out the answer.
Ready? The method A runs on a thread pool thread the first time, and then it runs on the UI thread the last two times.
I strongly recommend you to read whole article for better understanding the StartNew method usage, but want to point out the last advice from there:
Unfortunately, the only overloads for StartNew that take a
TaskScheduler also require you to specify the CancellationToken and
TaskCreationOptions. This means that in order to use
Task.Factory.StartNew to reliably, predictably queue work to the
thread pool, you have to use an overload like this:
Task.Factory.StartNew(A, CancellationToken.None,
TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);
And really, that’s kind of ridiculous. Just use Task.Run(() => A());.
So, may be your code can be easily improved simply by switching the method you are creating news tasks. But there is some other suggestions regarding your question:
Use BlockingCollection for the storing the reports, and write a simple consumer from this queue to UI, so you'll always have a limited number of reports to represent, but at the end all of them will be handled.
Use a ConcurrentExclusiveSchedulerPair class for your logic: for generating the reports use the ConcurrentScheduler Property and for displaying them use ExclusiveScheduler Property.

How to wait until a value becomes added to ConcurrentDictionary or timeout occurs?

I have a task that should wait until a value has been added to a ConcurrentDictionary. If the value is added, it should stop waiting and continue its work. It should stop waiting as well if a timeout occured (5 seconds for example).
The value should be added to the ConcurrentDictionary by another thread/task, however, due to the nature of the code, I do not want the threads to communicate with each other.
How I should go about implementing this (in C#) ?
Btw I am using Tasks, not Threads for most of the part, and thus I am not sure if Thread.Sleep or other methods on the current Thread would be a good decision, cause it might sleep other tasks which use the same thread and cause random problems.

I think "waiting" for an element to be added to a collection is generally a bad thing. Doing this, in general, means that a thread is blocked for some period of time. If it's even possible, you then have to deal with timeouts. If it's not possible to detect timeouts then you have to deal with aborting the thread to abort the wait (you never want to get into a situation where a thread is blocked indefinitely) e.g. cancellation.
ConcurrentDictionary is thread safe in and of itself; but this doesn't make all code that uses ConcurrentDictionary thread safe. The application-specific thread-safety requirements need to still be taken into account when using a ConcurrentDictionary object. ConcurrentDictionary cannot possibly implement those types of things. What to do when a value is added to the dictionary is also very similar--the overhead of waiting or notifying external code upon new value additions would cause all usages of ConcurrentDictionary to be slower, even those usages that don't need to wait or don't need to be notified--so things like that are not implemented. The fact that an application adds a value and needs to be notified that a value was added is probably pretty rare (from the dictionaries point of view, why would it tell you that you just added a value...). So, that sort of application-specific thing is normally done at the application level. i.e. the fact that a concurrent dictionary is used is a coincidence and your application notifies other threads that another thread has done something they need to know about. This could mean wrapping adds to a dictionary instance with calls to ManualResetEventSlim.Reset/Set and something can wait with a ManualResetEventSlim.Wait override. Or, it could simply be a matter of writing an event that gets raised whenever a value is added to the dictionary.

I don't believe ConcurrentDictionary provides any hooks for things like this.
You could potentially either wrap or derive from ConcurrentDictionary to provide this, but I'd be nervous of doing so.
The low-tech alternatively is simply to poll - loop round, checking and then sleeping, until you either find the right value or time out. It's far from great from an efficiency point of view, but it's probably the simplest approach if it doesn't give you any other problems.

This is how the sleep polling could work. Quick and dirty. :)
System.Collections.Concurrent.ConcurrentDictionary<string,string> dic = new System.Collections.Concurrent.ConcurrentDictionary<string,string>();
int timeoutCount = 0;
bool hasTimedOut = false;
while (!dic.ContainsKey("KeyYouAreLookingFor"))
{
//5 minutes has expired
if (timeoutCount >= 10)
{
hasTimedOut = true;
break;
}
//30 second sleep or whatever you want your poll time to be
System.Threading.Thread.Sleep(30000);
timeoutCount++;
}
if (hasTimedOut)
{
//TODO: timeout code
}
else
{
//TODO: Key has been added
}

When is the GUI overloaded?

Suppose you are permanently invoking a method asynchronously onto the UI thread/dispatcher with
while (true) {
uiDispatcher.BeginInvoke(new Action<int, T>(insert_), DispatcherPriority.Normal, new object[] { });
}
On every run of the program you observe that the GUI of the application begins to freeze after about 90 seconds due to the flood of invocations (time varies but lies roughly between 1 and 2 minutes).
How could one exactly determine (measure ?) the point when this overloading occurs in order to stop it early enough ?
Appendix I:
In my actual program I don't have an infinite loop. I have an algorithm that iterates several hundred times before terminating. In every iteration I am adding a string to a List control in my WPF application. I used the while (true) { ... } construct because it matches best what happens. In fact the algorithm terminates correctly and all (hundreds) strings are added correctly to my List but after some time I am loosing the ability to use my GUI until the algorithm terminates - then the GUI is responsive again.
Appendix II:
The purpose of my program is to observe a particular algorithm while it's running. The strings I am adding are log entries: one log string per iteration. The reason why I am invoking these add-operations is that the algorithm is running in another thread than the UI thread. To catch up with the fact that I can't do UI manipulation from any thread other than the UI thread I built some kind of ThreadSafeObservableCollection (But I am pretty sure that this code is not worth posting because it would detract from the actual problem what I think is that the UI can't handle the repeatedly and fast invocation of methods.

It's pretty straight forward: you are doing it wrong by the time you overload the user's eyeballs. Which happens pretty quickly as far as modern cpu cores are concerned, beyond 20 updates per second the displayed information just starts to look like a blur. Something the cinema takes advantage of, movies play back at 24 frames per second.
Updating any faster than that is just a waste of resources. You still have an enormous amount of breathing room left before the UI thread starts to buckle. It depends on the amount of work you ask it to do, but typical is a x50 safety margin. A simple timer based on Environment.TickCount will get the job done, fire an update when the difference is >= 45 msec.

Posting that often to the UI is a red flag. Here is an alternative: Put new strings into a ConcurrentQueue and have a timer pull them out every 100ms.
Very simple and easy to implement, and the result is perfect.

I've not used WPF--just Windows Forms, but I would suggest that if there is a view-only control which will need to be updated asynchronously, the proper way to do it is to write the control so that its properties can be accessed freely from any thread, and updating a control will BeginInvoke the refresh routine only if there isn't already an update pending; the latter determination can be made with an Int32 "flag" and Interlock.Exchange (the property setter calls Interlocked.Exchange on the flag after changing the underlying field; if the flag had been clear, it does a BeginInvoke on the refresh routine; the refresh routine then clears the flag and performs the refresh). In some cases, the pattern may be further enhanced by having the control's refresh routine check how much time has elapsed since the last time it ran and, if the answer is less than 20ms or so, use a timer to trigger a refresh 20ms after the previous one.
Even though .net can handle having many BeginInvoke actions posted on the UI thread, it's often pointless to have more than update for a single control pending at a time. Limit the pending actions to one (or at most a small number) per control, and there will be no danger of the queue overflowing.

ok, sorry for the bad link before in the comments, but I kept reading and maybe this will be of help:
The DispatcherOperation object returned by BeginInvoke can be used in several ways to interact with the specified delegate, such as:
Changing the DispatcherPriority of the delegate as it is pending execution in the event queue.
Removing the delegate from the event queue.
Waiting for the delegate to return.
Obtaining the value that the delegate returns after it is executed.
If multiple BeginInvoke calls are made at the same DispatcherPriority, they will be executed in the order the calls were made.
If BeginInvoke is called on a Dispatcher which has shut down, the status property of the returned DispatcherOperation is set to Aborted.
Maybe you can do something with the number of delegates that you are waiting on...

To put supercat's solution in a more WPF like way, try for an MVVM pattern and then you can have a separate view model class which you can share between threads, perhaps take locks out at apropriate points or use the concurrent collections class. You implement an interface (I think it's INotifyPropertyChanged and fire an event to say the collection has changed. This event must be fired from the UI thread, but only needs

After going through the answers provided by others and your comments on them, your actual intent seems to be ensuring that UI remains responsive. For this I think you have already received good proposals.
But still, to answer your question (how to detect and flag overloading of UI thread) verbatim, I can suggest the following:
First determine what should be the definition of 'overloading' (for e.g. I can assume it to be 'UI thread stops rendering the controls and stops processing user input' for a big enough duration)
Define this duration (for e.g. if UI thread continues to process render and input messages in at-most 40ms I will say it is not overloaded).
Now Initiate a DispactherTimer with DispatcherPriority set according to your definition for overloading (for my e.g. it can be DispatcherPriority.Input or lower) and Interval sufficiently less than your 'duration' for overloading
Maintain a shared variable of type DateTime and on each tick of the timer change its value to DateTime.Now.
In the delegate you pass to BeginInvoke, you can compute a difference between current time and the last time Tick was fired. If it exceeds your 'measure' of overloading then well the UI thread is 'Overloaded' according to your definition. You can then set a shared flag which can be checked from inside your loop to take appropriate action.
Though I admit, it is not fool proof, but by empirically adjusting your 'measure' you should be able to detect overloading before it impacts you.

Use a StopWatch to measure minimum, maximum, average, first and last update durations. (You can ouput this to your UI.)
Your update frequency must be < than 1/(the average update duration).
Change your algorithm's implementation so that it iterations are invoked by a multimedia timer e.g. this .NET wrapper or this .NET wrapper. When the timer is activated, use Interlocked to prevent running a new iteration before current iteration is complete. If you need to iterations on the main, use a dispatcher. You can run more than 1 iteration per timer event, use a parameter for this and together with time measurements determine how many interations to run per timer event and how often you want the timer events.
I do not recommend using less than 5mSec for the timer, as the timer events will suffocate the CPU.
As I wrote ealier in my comment, use DispatcherPriority.Input when dispatching to the main thread, that way the UI's CPU time isn't suffocated by the dispatches. This is the same priority the UI messages have, so that way they are not ignored.

C# Thread.Sleep() cause lag

Ok, i have problem in C#. In my script Threading.Sleep() cause lag, i think i'm doing something wrong, this is part of source:
case 2:
{
mouse_event(MOUSEEVENTF_LEFTDOWN, Pos.X, Pos.Y, 0, 0);
mouse_event(MOUSEEVENTF_LEFTUP, Pos.X, Pos.Y, 0, 0);
SendKeys.Send(textBox1.Text);
Thread.Sleep(300);
SendKeys.Send("{ENTER}");
break;
}
I want to send text, wait for 300 milliseconds and send enter, but i just receive lag for that time and everything is done without waiting.
Maybe there is something alternative to it?

What do you mean by lag? In this case without having much context it looks like you are blocking the main thread which it what then locks up your application for the duration of Sleep(). You also said you want to sleep for 300 milliseconds but you have 1000 passed to the function. Use something like a BackgroundWorker to put the logic for sending the text in a background thread so you don't block the UI while it's happening.

What do you mean by getting lag? I'm guessing this is how you are describing the time that your code is spending sleeping.
Perhaps you might want to look at a Timer class [0] that you can then bind the later code to as an event.
[0] Three timer classes are available described here: http://msdn.microsoft.com/en-us/magazine/cc164015.aspx. I tend to use the System.Timers.Timer class.
Edit in response to comment:
You need to think about what you mean by "do nothing". Doing nothing includes not updating the UI or anything. Literally do nothing. I'm assuming this is what you are describing as lag. To get around this there are the two methods described in the two answers. Both ultimately involve using threads so that the main thread can continue to allow the UI functionality can happen while your secondary thread can do work.
My method would involve a timer. When you want the program to stop for a bit you create a timer with an event that will fire at the end of your pause. That event then calls the method you want to run at the end of that time. This may require a bit of refactoring of your code.
The other method involves spawning a separate that your other code can run in. Becuase this is a secondary thread sleeping this will not effect the responsiveness of the rest of your application, just of that one thread so it shouldn't matter. This may well be the easiest way of doing things.
One thing is for sure though that if you aren't really very comfortable or familiar with how multiple threads in one application works then you might want to do some general reading first.