Running xunit tests in Silverlight–xunitcontrib-silverlight

by Matt 14. December 2010 12:14

If you want to write unit tests in Silverlight,  it’s a pretty solid bet that you’ll be using using Jeff Wilcox’s unit testing framework that ships with the Silverlight Toolkit. It’s essentially a port of mstest, combined with a Silverlight based test runner. Handily, the test runner allows for unit test providers, allowing us to plug in a different test framework.

And that’s exactly what the latest release of xunitcontrib is – a port of, and a provider for the unit testing framework.


It’s a pretty faithful port of xunit (i.e. with as few changes to the source as possible), and includes the majority of the features that you’ll require day-to-day for testing, but it’s also running on a different platform and in a different execution environment to the desktop CLR version of xunit, so THERE ARE DIFFERENCES.

I strongly suggest checking out what’s different or not included in the xunit port, as well as the details of the unit testing framework integration.

In the mean time, you can download the release from codeplex. It supports Silverlight 4 using the April 2010 toolkit and Silverlight 3 using the semi-official build based on the April 2010 toolkit (Windows Phone 7 support is coming in the next release). Here’s the quick run down on how to use it:

  1. Create a Silverlight application
  2. Add references to Microsoft.Silverlight.Testing.dll and the Silverlight-appropriate versions of xunit-silverlight.dll, xunit.extensions-silverlight.dll and xunitcontrib.runner.silverlight.toolkit.dll
  3. In App.xaml.cs, replace Application_Startup with:
          UnitTestSystem.RegisterUnitTestProvider(new XunitContrib.Runner.Silverlight.Toolkit.UnitTestProvider());
          RootVisual = UnitTestSystem.CreateTestPage();
  4. Then just add tests, and run the application

Alternatively, if you’ve installed the latest Silverlight Toolkit, you’ll get a unit testing project template in the File->New dialog that makes this a little easier, although you’ll still need to add the xunit/xunitcontrib references and register the xunitcontrib provider (if you don’t register it, you’ll get no tests!)

As ever, let me know, either via codeplex or on twitter (@citizenmatt) if there are problems or questions.


xunitcontrib | Silverlight

The Dynamic Language Runtime

by Matt 28. May 2007 18:06

How cool is the DLR? Go and read that link; read the code and understand what it does. I'll be here with a paracetamol and a cup of sweet tea. Seriously fruity, isn't it?

Yep, that's the Dynamic Language Runtime announced at Mix 07. (We've already covered that I'm late with the Mix analysis. Get over it.) I like this. A lot. It's perhaps a shame then that I don't actually get dynamic languages (or perhaps - get the need for dynamic languages). But that's another post.

This eweek article is a good introduction, but briefly, consider this a set of BCL extensions to simplify lightweight dynamic code generation and dynamic dispatch - true late binding languages.

We're getting a few new languages out of this. IronPython's been the driving force behind all of this, and 2.0 now uses it. IronRuby is coming. The current plan for Visual Basic is to use it for VBx (VB 10). (That's a big statement, so also read the announcement from the VB team and this post clarifying future plans.) This can only be a good thing. I think we need a bit more diversity between VB and C#. More interestingly, there's also a DLR version of Javascript in the pipeline (this isn't, just to confuse things - oh, and it's implemented in Visual Basic to boot).

(And doesn't that just make you wonder if the IE team are going to pick up managed Javascript to replace the aging ActiveScript based implementation? It's slow and prone to circular memory leaks, and .net has garbage collection and a 1000x performance increase. Yeah. 1000x.)

Did I mention it was available on Codeplex? It's currently a part of IronPython, which is some flavour of open source. This means Mono can just use it, legally. And in just 16 days, technically.

Speaking of Mono, Miguel de Icaza has had a run of blog posts about a compiler workshop Microsoft has been running on the DLR (yeah, that's the Mono guys working with the Microsoft guys. You know, cats and dogs, living together, that kind of thing). And he's looking at a Linux version of Silverlight, currently codenamed Moonlight. (Mono is an interesting project. I like the idea of .net on Linux and Mac et al, but it just makes me feel sorry for them that they have to constantly chase Microsoft's libraries - WCF, WPF, Silverlight, etc.)

But surely the most intriguing part of the DLR is the delivery mechanism. Why Silverlight? This library has the potential to have a huge impact on the ecosystem of .net. If Microsoft get it right, it's going to open the runtime up to a whole heap of developers who wouldn't otherwise have gone near .net.

And it's being delivered as a browser plugin.

Now, it does have a hosting model so that it can be integrated with the desktop CLR, but it's a bit of a surprise that this isn't being packaged in with .net 3.5. Perhaps it's just a question of timing? Is it too late in the day, and the DLR too immature? An alpha technology might very well be a better suited home. Or perhaps it's the cross platform nature of Silverlight; couple this with open-sourced dynamic language support and you've suddenly got a number of things to get the alpha geeks interested.

Either way, Microsoft are moving in some impressively different directions with this. I'm going to keep an eye on this one.



Silverlight and the CoreCLR

by Matt 23. May 2007 17:57

So I'm only really just catching up with the fun and games of Mix07. (The kitchen has a lovely new coat of paint, the holiday was nice, but plagued with minor illness and my work project has just been put on hold. I've been busy, alright?)

I don't really want to simply regurgitate the list of new products here, but there are a few things of interest I'd like to comment on. I have a feeling I'm going to be using the word "interesting" a lot...

Of course, Silverlight was the star of the show. They've revved the beta version and apart from the rebranding, one thing to catch my eye was the use of the ASP.NET AJAX style of JavaScript (namespaces, classes, etc) in the launcher scripts. Reinforces that it's an integral part of the ASP.NET family. Nice.

But who's looking at the 1.0 beta? It's already old news - Microsoft have taken the very interesting step of also releasing an alpha version of 1.1. Is this a good way to stop the "waiting for SP1" mentality? (If so, they're using the same tactic with Expression Blend - releasing the RTM of v1 and the beta of v2 on the same day.)

Yeah, 1.1 is where it's at. I don't think anyone was really surprised with the CLR in the browser. No, I think the big surprise is that's it's not the tiny CLR - it's the real deal. It's a slimmed down version of the .net 2 runtime engine. Aside from BCL changes, I think the main thing that's missing is the CAS security model and P/Invoke and COM interop, but essentially, it's the desktop CLR. It can run side-by-side in-process with the desktop version (which could mean scary things when both CLRs want to suspend threads for garbage collection). I'm also wondering what the ramifications of this refactoring will be on the desktop version. Will any of these changes filter back up? Will the CoreCLR be a true subset of the desktop version? Or will it become like the .net Compact Framework, where classes don't have all the same methods and properties, making compatibility a bit of a challenge.

Just to show how cutting edge it is, it's based on .net 3.5 - it's got some LINQ stuff in, but no heavy duty implementations, just LINQ over objects, with LINQ over xml coming soon. Microsoft have posted a very useful little diagram with the supported namespaces and classes which shows the ambitious scope for this. The System.Windows.Browser namespace looks fun - another API for accessing the DOM? But the best bit of the diagram is support for WCF. A client side WS-* stack (hopefully with CardSpace support) in a cross platform (ah, probably not with CardSpace, then) browser plugin for just a couple of meg? I'm pretty close to thinking that's the holy grail.

I'm really looking forward to playing with Silverlight. There's a huge amount of technical innovation going on here that deserves a lot of study and comment.

Not the least of which is the Dynamic Language Runtime...



Jon Udell: Rewriting the enriched web

by Matt 26. April 2007 02:19

Bingo. Jon Udell's been joining the dots. He's made the connection between Silverlight's script-accessible object model and Javascript. In fact, he ratchets it up a notch - Greasemonkey scripts modifying Silverlight controls on a 3rd party site. That's really very powerful.

Is it actually Silverlight's secret weapon? Well, maybe not. Adobe has the Flex-Ajax Bridge, which exposes Flex and swf ActionScript to a hosting web page's Javascript. It's not as deeply integrated as in Silverlight, where it seems more of a philosophy than an implementation/component (and it looks like it's still a beta).

So, perhaps this isn't Silverlight's unique selling point, but I still think this is a great development model, and Silverlight may well prove the tipping point for this kind of design.



So why does Silverlight need the CLR?

by Matt 23. April 2007 17:21

Ah. Good question. If Silverlight's "killer feature" is its Javascript accessable object model, why would Microsoft embed a .net CLR in the control?

Well, there's only so much you can do in Javascript and a browser. You don't get xml parsing support (otherwise JSON wouldn't exist). You can't call web services without a lot of pain, and lack of encryption means WS-* is just out of the question.

Imagine adding support for zip. Mix in a decent xml parser, and all of a sudden, you can now process XPS or Office 2007 files in the browser. That'd make Google Docs more interesting.

Javascript doesn't give you access to the local file system, and for very good security reasons. But given a sandbox with finer grained security permissions, and the file system might come into reach.

I keep thinking that this could be the next evolutionary step for the browser. I think we've all but hit the glass ceiling of what the browser will allow us to do. We need more client side capabilities (local storage, network connectivity, encryption, you name it). Does this come from objects exposed by the browser, Javascript libraries (which would have to be in source format) or pre-parsed/pre-compiled IL libraries?

Embedding the CLR, and especially elements of the Base Class Library could actually see Microsoft doing ActiveX properly; a secure, powerful binary extension mechanism.

And seeing how grandiose this is all getting, how about open-sourcing the whole thing and getting Firefox and Apple to buy into it?



Silverlight doesn't *need* http capabilities

by Matt 22. April 2007 18:12

Jeff Atwood's just taken to task some bloggers that haven't done their homework. Personally, I'd have taken them to task for writing in all-caps bold, but that's just me.

I know this is completely orthogonal to Jeff's point, but I'd like to tackle the Silverlight complaints. These were simple - you can't download from a Silverlight control, and there's no databinding or controls. The latter one I can't argue with (although there are hints that there will be a large announcement at mix07 - I'm thinking either controls or tiny CLR support), so let's look at the first.

Saying that Silverlight can't make http requests really misses the point. As Jeff points out, it does actually support a "downloader" object that is very much like XmlHttpRequest; it just adds progress notifications. Ok, that solves the problem, but it ignores the bigger picture - the reason Silverlight is not your traditional browser plugin.

Compare it to Flash (but not in the obvious way). Flash is (mostly) very self contained. You create a .swf file that contains graphics, sound, layout and script. It uses the capabilities of the Flash virtual machine to do anything it needs to do. Silverlight approaches this from the other direction. You give it a loose XML based XAML file. Silverlight downloads whatever resources you reference in it. If you want any logic, you write Javascript in your page, not in the control. You want to download more stuff? Use XmlHttpRequest.

This is a brilliant, simple and very effective idea. We've seen huge advances - and takeup - in the use of Javascript and XmlHttpRequest. Why reinvent the wheel?

Silverlight's secret weapon is its browser-scriptable object model.



Now that explains the "ag"...

by Matt 16. April 2007 16:30

WPF/e is now called Silverlight. Quite a nice name, perhaps a little cold, doesn't exactly roll of the tongue, but it's better than Microsoft's usual overly descriptive attempts.

More importantly, it joins the dots on why the scripts and mime type where referencing "ag" (agHost, ag-plugin, etc). Isn't it nice when loose ends get tidied up like this?



Month List


Comment RSS