Comments on: Asynchronous test support – Silverlight unit test framework and the UI thread

By: Phil Cockfield

Phil Cockfield — Sun, 24 May 2009 21:28:54 +0000

Awesome Jeff!!!

By: Jeff Wilcox

Jeff Wilcox — Sat, 23 May 2009 21:55:31 +0000

@Phil,
Wow, yeah, that’s something I’ve really wanted to investigate. It would mean removing the HTML interop loggers, and removing some of the singletons from the implementation today. There’s also the unhandled exception handler logic, that could stay, but would affect any kind of asynchronous/multiple-concurrent test runs.

I’ll see what it might take and either blog on it, or respond back here!

By: Phil Cockfield

Phil Cockfield — Sat, 23 May 2009 20:49:57 +0000

Hi Jeff,

Rather than send you a private comment, I’ve taken the advice on your comment page, and am posting on the latest post re your Testing Framework.

I was wondering if there is a way to get more programmatic control over the testing framework – rather than having it take over the page (Root Control), could we instantiate it as a control, and run it diagrammatically receiving test results back as a data-object rather than in UI.

This would make it possible to integrate this into a wider testing story…drawing on the pre-investment in silverlight tests.

If it already does this, apologies, and I wonder if you could point me in the direction of how to do this please.

This would be really awesome, and powerful…and I’m sure would see your framework become the core of many more value-add mash-ups around testing.

Thanks – I’d love to hear your opinion on this. Thanks.

By: Santhosh C

Santhosh C — Mon, 04 May 2009 06:57:34 +0000

1) Does Silverlight UT framework has a UI similar to Nunits ?
2) Is it possible to run only partial test cases similar to Nunits, where i can run only selected ‘TextFixtures’ ?

By: Mock

Mock — Fri, 27 Mar 2009 08:25:41 +0000

Great article Jeff…

Jonas – we’ve just started a new open source project – SilverUnit – that is capable of unit testing Silverlight and WCF

http://www.typemock.com/Silverlight_unit_testing_page.php

By: Scott

Scott — Tue, 10 Mar 2009 19:37:00 +0000

@Jonas:
EnqueueCallback(delegate
{
// Waiting for WCF to return
m_PropertyChangedEventTrap.WaitUntilReceived(1);
Assert.AreEqual(3, m_RoutesViewModel.Routes.Count);
TestComplete();
});
}

Try taking the TestComplete(); out of the EnqueueCallback.

By: Jonas Karlsson

Jonas Karlsson — Fri, 06 Mar 2009 07:18:41 +0000

Thought I replied, but here’s a new post.

What we want to achieve is a functional integration testing in a similar manner as when we develop windows forms by:

1. Injecting stimulus on client side
2. Waiting for server to complete WCF call
3. Evaluating the result on the client side

This is a common practice in testing asynchronous solutions.

The problem is to get the test to actually execute the WCF call, since the BeginXXX-method does not fire away the call immediately but enques the call. The dequeueing takes place when the UI thread is done, see e.g. article http://www.codeproject.com/KB/silverlight/SynchronousSilverlight.aspx.

I was accordingly hoping that the WCF-call would get a chance to execute, before entering the delegate. But it doesn’t. If I take away the event trap (which indeed is blocking, to assure #2 above) the WCF call is executed after the TestComplete. Which is way too late.

By: Jonas Karlsson

Jonas Karlsson — Thu, 05 Mar 2009 10:32:16 +0000

The event trap is waiting for the WCF-call to have been completed. We don’t want to evaluate the result on client side until we know the server return is completed. This is a common practice in testing asynchronous calls. So, yes it is blocking since the WCF call is not executed at all and accordingly not completed. If I take away this trap, the WCF call is executed *after* TestComplete which does not help me. I was hoping the UI thread would get a chance to dequeue the WCF-calls before entering the EnqueueCallBack delegate.

By: Jeff Wilcox

Jeff Wilcox — Wed, 04 Mar 2009 16:40:41 +0000

@jonas,
What does your property changed event trap do? You may not actually need it, since it may block one of the key threads.

By: Jonas Karlsson

Jonas Karlsson — Wed, 04 Mar 2009 15:31:18 +0000

Thanks for this article! This was exactly what I was looking for. At least I thought.

We are evaluation this framwork for our functional testing, where we have a Silverlight/WCF-solution. By injecting stimulus on the GUI and evulating the service results, we cover most part of our system.

The issue I’ve been strugling with is that the WCF call is enqued and not executed immediately as it is invoked from the UI thread.

Now I tried the EnqueueCallback described in this article. See snippet below. It didn’t help. The WCF call was not executed between the test method is completed and the EnqueueCallback is entered.

//
[TestMethod]
[Asynchronous]
public void TestGetRoutes()
{
m_RoutesViewModel.DateTimeFrom = DateTime.Now;
m_RoutesViewModel.DateTimeTo = DateTime.Now;
m_RoutesViewModel.GetRoutes();

EnqueueCallback(delegate
{
// Waiting for WCF to return
m_PropertyChangedEventTrap.WaitUntilReceived(1);
Assert.AreEqual(3, m_RoutesViewModel.Routes.Count);
TestComplete();
});
}