So today I was perusing my blog list and ran across a blog by Rick Strahl (Dynamic Delegates with Expression Trees) which is referencing this post by Nate Kohari (Fast Late-Bound Invocation with Expression Trees).

I first just thought it was a very interesting post and thought, “wow, next time I have to do something requiring a ton of reflection method calls I’ll have to remember this”. I took off with the family for the day and sometime during the day the idea popped into my head about trying it to read property’s values (since they are actually just a method call under the hood). And I do have the perfect place to try and spike this idea…

One of the things I’ve done to the i4o library is try to reduce the calls to reflection whenever possible. And the only one left that I couldn’t get past was having to use the PropertyInfo’s GetValue reflection call to get at a value for creating the property index. This generally isn’t a big deal because we only have to do it once, however it makes the initialization of the IndexableCollection<T> fairly expensive.

So I decided to spike the idea of using the DelegateFactory from Nate’s blog to read an object’s property values. And below I’m including the project that I spiked to test this idea out.

It compares how fast we can read values out of an object’s property by first using reflection and second using the dynamic delegate.

If you read Ricks post above, he mentions how the dynamic delegate idea is a little reflection expensive up front. However it only happens once and I ran a couple of tests…(p.s. i noticed a small flaw in my timing, however I don’t want to re-zip & re-upload the spike… so if you see the timing flaw, cool…)

I noticed that after about the first 5000 reads the expense of the heavy up front reflection from DelegateFactory started to become negligent. And the more reads the more powerful the new reading strategy became. Take 1/5 million reads for example… normal reflection reading took .78 seconds, while the delegate reading took only .03 seconds which is a substantial increase.

After that I spiked it in the i4o project and proved that this could significantly increase the index build time of the an IndexableCollection<T>. I shelved the spike and am having Aaron take a look at the idea. We’ll see, I haven’t come up with any reasons why this could cause any issues, so it may be included…

Moq 3.0 has been officially released and it comes with full Silverlight Support. You can download them here http://moq.me/get

Now that it is official and when I get some spare time I will try and place my UnityAutoMocker up in the moq-contrib project shortly.

If you've been doing any Silverlight development, I'm sure you're aware of the Microsoft Silverlight Unit Test Framework.

One extremely interesting aspect about this framework is how flexible it is for custom extension. If you didn't already know, Jeff Wilcox put together a quick port of NUnit and created a project that would interface the nunit.framework.dll he ported with the Microsoft Silverlight Unit Test Framework. (post here)

Below I'll explain a little about my port of the xUnit testing framework that is now hosted in the browser leveraging the Microsoft Silverlight Unit Test Framework.

As far as WHAT is implemented with the xUnit for Silverlight and what you may have to figure out on your own (as I'm not all that familiar with xUnit) if you use it for your own project...

1. FactAttribute ( obviously )
2. FactAttribute.Skip ( [Ignore] in most frameworks )
3. FactAttribute.Name (is mapped to the "Description" in the ms test harness)

That's pretty much it... It doesn't do anything as far as test Setup/Teardown as Moq (the project I needed xUnit in Silverlight for) didn't need it, and because I'm not familiar enough with xUnit to really make this thing fully compatible.

So, here is XunitLight for Silverlight...

UPDATE: (2/9/2009) If you'd like to provide any updates to this project. You can get the source from below and I'm happy to take a look at patches...
http://svn.xp-dev.com/svn/staxmanade_projects/XunitLight.Silverlight/

If you read my previous posts about [Fluent] Specification Extensions then you know that I'm still in an experimental phase of this idea.

1. Fluent Specification Extensions
2. (+1) for [Fluent] Specification Extensions

There are two more things I've found that are going against the specification extensions idea. The first one below is related to all specification extensions, not just the fluent flavored specification extensions.

-1. If you have a test that for some reason has an assertion in the middle of some code.

[Fact]
public void MockAsExistingInterfaceAfterObjectSucceedsIfNotNew()
{
	var mock = new Mock<IBag>();

	mock.As<IFoo>().SetupGet(x => x.Value).Returns(25);

	((IFoo)mock.Object).Value.ShouldEqual(25);

	var fm = mock.As<IFoo>();

	fm.Setup(f => f.Execute());
}

It's a little difficult to tell where the assertion is because you don't get the syntax highlighting help from the static class name "Assert".

Assert.Equal(25, (IFoo)mock.Object);

However I don't think the reason above is anything to stop using the pattern for a couple of the following:

1. How often do you have assertions in the middle of your code?
2. If you are doing your tests right, it doesn't take long to scan the above code for the ".Should..." extension method.

-1. Daniel from the Moq project tweeted Scott Bellware about his spec unit projects SpecificationExtensions.cs

@bellware shouldn't specunit ShouldNotEqual/etc. return the actual object rather than the expected? To chain other calls http://is.gd/iJuB

@bellware and ShouldBeNull/NotBeNull could also return the object: obj.ShouldNotBeNull().ShouldEqual(...), right?

with Scott's response being...

@kzu no because that would contribute to crowding many observations into a single method

To that I say, True, if you are doing pure Context/Specification based unit testing. However most of us aren't actually doing it (maybe we should?) so why not allow the test to say

someString
  .ShouldNotBeNull
  .ShouldEqual(...)?

So for now... I'm going to continue to go with the Fluent Specification Extensions.

If you read my previous post about Fluent Specification Extensions then you know that I'm still in an experimental phase of this idea.

I'd like to share one more positive I found by using the specification extensions in my testing framework. This benefit is there weather you use standard specification extension methods or try the fluent specification extensions. The idea is very basic, but I didn't even realize it's benefit until I ran into it directly.

And the great benefit is... (drum roll...errr..actually it's not mind blowing). By using extensions methods to provide assertion extensions on the objects we're testing, we've abstracted the actual testing framework's assertion process. (told you it wasn't mind blowing, but read along and see an example of how this abstraction could be good)

Now I know most times you won't ever change testing frameworks, however I just ran into this when attempting to port the Castle.DynamicProxy2 (DP2) to Silverlight. Their test project leveraged the NUnit testing framework, which hasn't officially been ported. You can find a quick port by Jeff Wilcox that will run in the Microsoft Silverlight Unit Testing Framework. However when I was porting the DP2 that hadn't been done, and I didn't feel like porting NUnit at the time.

So, by providing this abstraction layer (through the extension methods). You could then go in and easily swap what testing framework your project is leveraging to do it's assertions.

NOTE: the port from NUnit to MSFT wouldn't have been that easy as the [TestMethod] in MSFT is sealed so I couldn't create a [Test] attribute that inherited from [TestMethod] to get the SL testing framework to run the tests w/out changing the DynamicProxy test code...aside from that issue...

Let's take a concrete example of this abstraction benefit.

Notice how the Assert.IsInstanceOfType() in both NUnit and Microsoft's testing framework have the parameters reversed.

NUnit:

Microsoft:

If you were trying to switch from NUnit to MSFT or visa versa, a simple search and replace on [Test] for [TestMethod] would suffice for the majority of the needed port. However the Assert.IsInstanceOfType() would fail at compile time because of the parameter order. (and who know what else exactly is different)

If you could provide that layer of abstraction for the assertions, then to switch between NUnit and MSFT or visa versa would remain very simple, as you would only have to provide the framework specific changes only once.

FYI: If you're familiar with extension methods, and how to use them in testing sceneries...the interesting part of this post is at the bottom starting at: "Ok, on to the point..."

The C# extension methods give some amazing power when it comes to extending functionality of objects (we don't own) and I've spotted a pattern on several blogs and example unit testing snippets, especially in the Context Specification style testing areas that I find interesting.

The concept is to basically use the C# extension methods within a unit testing environment to give the system under test (SUT) more readability/understandability within the test code itself.

Here's an example of how you might normally write a unit test given the following SUT.

public class SystemUnderTest
{
  public SystemUnderTest() { PropertyUnderTest = "Hello World!"; }
  public string SomeStringProperty { get; set; }
  public bool SomeBoolProperty { get; set; }
}

You might write some unit tests that might look like...

var sut = new SystemUnderTest();

Assert.IsTrue(sut.SomeBoolProperty);
Assert.AreEqual(sut.SomeStringProperty, "Hello World!");

Now, the assertions above are small enough it's pretty easy to tell what's going on, however when you think about what your looking at, it actually present the best readability.

Let's take the string's AreEqual assertion for example...  You first read the "AreEqual", so now you have to allocate some (undefined as of yet) space in your head to store some data points that need to be evaluated all at once. (maybe I'm getting lazy as I get old, but the less I have to think when reading tests the more time I can spend understanding the domain being tested...)

Again, the example is over simplified, but I think you get the point.

What if you could make the test syntax read and flow in a very readable and understandable manner?

That's what the specification extensions give you. Given the two tests above and an a couple helper extension methods living in the testing library I could write something like.

var sut = new SystemUnderTest();
sut.SomeBoolProperty.ShouldBeTrue();
sut.SomeBoolProperty.ShouldEqual("Hello World!");

It may just be me, but that just feels better, is more understandable, and the great thing is I didn't have to impact my domain objects to support this style of test...

Another great benefit is you don't have to type "Assert.xxxx(YYzzz)" each time you want to create an assertion. You can just type sut.SomeThing.{this where you get help from intellasense} giving you some great context based assertion options.

I googled for a library that had a pre-built set of extension assertions and ended up finding the http://code.google.com/p/specunit-net/source/browse/ by Scott Bellware. If you dig into the source of the project you can find a helper class called SpecificationExtensions.cs which basically gives you all the "Should..{your assertion here}" extension methods.

Ok, on to the point real point (sorry it's taken so long).

After downloading and playing with the extension specifications from Spec Unit, I thought what if we made that more fluent?

So I gave it a quick spike and instead of writing some tests that look like...

sut.SomeStringProperty.ShouldNotBeNull();
sut.SomeStringProperty.ShouldBeOfType(typeof(string));
sut.SomeStringProperty.ShouldEqual("Hello World!"); 

You could have less wordy code and still retain all the meaning and readability with a set of fluent specification extensions.

sut.SomeStringProperty
.ShouldNotBeNull()
.ShouldBeOfType(typeof(string))
.ShouldEqual("Hello World!");

I haven't figured out what sorts of bad things this style of assertion could bring... but we'll experiment for a while...

Here's an example console app with the extensions included.

DISCLAIMER: I haven't tested all the extensions so if you notice any issues please feel free to let me know...

A couple weeks back I threw out a Teaser about a Silverlight AutoMocker... Here's the follow up I promised.

UPDATE: Moq 3.0 released with full Silverlight support http://moq.me/get

I've been working on this off and on for a while now, and finally decided to sit down and finalize (at least this version) of both Moq for Silverlight and an AutoMocking container backed by the Unity IoC from Microsoft.

This isn't by any means "Official", but probably not far from what will be coming out when it's done...

Below are the necessary steps (I can come up with) to get an official version of Moq.

1. We need an "Official" build of the Castle.DynamicProxy2 dependency
   1. Create NAnt build scripts (Jonathon Rossi said he'd try to work on it this weekend 1/23) Thank God! It tried porting the NAnt build to Silverlight and each of the 3 times I got so lost I gave up... :(
   2. Fix the Castle.Core-Silverlight build (some changes have occurred to the main without being pushed to the Silverlight Version)
   3. Create an official binaries of
      1. Castle.Core
      2. Castle.DynamicProxy
2. Port Moq to Silverlight
   1. I supplied a patch to Daniel a while ago, but he said he wouldn't include it until #1 above.

But until the official versions become available, here are what I have so far!!!

UPDATE: oops, realized I posted the files below as .7z. You can download and install the free open source zip utility here http://www.7-zip.org/

This contains the Moq, Moq-Contrib (w/unity AutoMocker) source

This contains all the binaries you need to run Moq...

Please keep in mind I'm by no means an IoC pro and the whole AutoMocker was a one afternoon attempt at throwing one together that I could use in Silverlight. It's very basic, but seems to support most of what I need for now.

Could an AutoMocking container backed by Moq and Unity be a project that the community needs?

Although we don't have an official Moq for Silverlight yet. You can go to the email list and pull the patch I submitted to get an early version up and running.

I have, in the queue of blog posts, a Silverlight AutoMocker leveraging the new Microsoft Unity container for Silverlight.

I'll wait till we get a full Silverlight version of Moq before posting.

P.S.

The existing Moq automocker for the full .NET framework, over at Moq-contrib, is leveraging the Autofac contianer, and when I threw my Silverlight version together Autofac hadn't been ported (yet), however just read a blog today that said it has an early port available.

I know what you're thinking (or at least what I was thinking before I knew better). What is the Castle.DynamicProxy and who cares it was ported to Silverlight?

To be honest I didn't know it existed until I tried to find a mocking framework for doing Silverlight unit testing. Then I found this thread over on the Moq mocking framework's home site which talked about needing to get the Castle.DynamicProxy ported before Moq could be ported to Silverlight.

Turns out, the DynamicProxy is one of the core dependencies of the two major open source mocking frameworks out there. (Moq, and Rhino Mocks)...(I'm sure there's others out there, but for now I only care about Moq because it's what we use at work)

After sitting around for about three months since I first read the thread and not hearing any word about the DynamicProxy being ported, I thought I'd take a stab.

Joined the castle devl email group, threw a ping about the port and I was off...after a couple weeks several late nights, and a few patch submittal turn-backs by hammett I finally got the patch in a place he liked and he applied it on Jan 3 2009.

What a great feeling of relief, this was a big step forward to getting full mocking support in Silverlight.

There is still one pending thing with the DynamicProxy & all Castle.Silverlight projects to date...we need to integrate the build and testing into their NAnt builds. Once that's done and a binary release is out, Moq port to Silverlight...here I come.

p.s. I already have a patch for Moq, but Daniel said he won't apply it till he can get the "official" binaries, which is fine. I would probably do the same if I were overseeing a decent sized open source project like Moq.

Soon enough...we'll have Silverlight mocking...

If you're doing any Silverlight development you've probably run into the problem "some method/property/functionality I'm used to using doesn't exist in the core framework" provided by Microsoft.

What are your options?

1. Write the logic yourself (you just might have to)
2. Use reflector on the full framework to see how it's done and attempt to (go back to step 1. )
3. Or one I've been using lately. Take a look at the Mono project.

DISCLAIMER: I'm not very familiar with much of the legal side of this option, so I highly recommend understanding Mono's licensing before going too far with their source.

However it's still a great source for learning how to implement something that was tucked away in the full framework's BCL.

And, with the power of Google, you can easily find what you're looking for...

Let's give an example:

Say, for instance, you need the IsNested property off of the System.Type object. The Silverlight version doesn't have that property, so let's go find out how it's implemented in Mono.

enter in a google serch: (we'll limit the search to the mono project's exposed svn site)

site:anonsvn.mono-project.com System.Type IsNested

The second link down is the one we want.

Then you can click on "View" in the "Links to HEAD"

And you end up looking at the .cs file source for System.Type. Just look in the page for the IsNested property and presto...

I'm beginning to love open source and the advantages it provides to the community as a whole. Thanks Mono.