I applied some updates to UnitDriven and released a new version recently. The updates provide some nicer nesting of namespaces in the test runner UI as well as improved disabling of ‘Run’ buttons and correctly functioning Timeouts.
Also the update is paired with updates to StatLight so you can run your Silverlight unit tests in a purely automated fashion.
Also, if you find yourself trying to remember why you would want to use UnitDriven instead of one of the other unit test frameworks for Silverlight, here are the main features.
- First class support for asynchronous tests.
- Supports the ability to author identical tests for Silverlight and .NET (file linking).
- Parallels either MSTest or NUnit seamlessly.
I was just encountering a bug with using the System.Threading.Timer object in Silverlight for UnitDriven. It was very non-intuitive and sporadic so I thought I’d post some of my conclusions here just in case.
The problem was, that if I had a test that contained a BackgroundWorker that called Thread.Sleep(x) in it’s DoWork event, the timer callback would never get called. I would set the timer to fire in 5 seconds then call sleep for 30. The timer would only fire after the sleep was concluded.
I believe this is the case because Silverlight only has 1 background thread, or at least the Timer and the BackgroundWorker are sharing the same thread. So even though the timers timeout has expired it cannot get CPU time to do the work and fire the callback. The solution I came up with was to, instead of using a timer, simply call Application.Current.RootVisual.BeginInvoke(this.CheckForTimeout) and do the calculation myself. That worked like a charm.
So my conclusion is that getting yourself onto the UI thread in Silverlight is a more reliable way of guaranteeing CPU time since the UI thread is more likely to pumping continuously. Of course too much of that and everything will seem sluggish. What I really need is a backround work queue, or a dispatcher for a background thread in other words.