Another limitation of testing Silverlight that me and one of my workmates ran into with mstest and VS2010 is documented below.
OOP especially Polymorphism help us here though.
We try to test a method that takes an ObservableCollection as input parameter.
I would like to leave the discussion about whether a method with a parameter of type "ObservableCollection" is a good idea or not to another day…
This is the method we want to write some tests around
public static bool Swap( ObservableCollection<int> sourceCollection, int index0, int index1) { //HACK Removed for blog //TODO Swap ;-) return false; }
And this is the 1st test that we are going to write
[TestMethod] public void WhenPassingNull_ShouldReturnNull() { Assert.IsFalse(Swapper.Swap(null, 0, 1)); }
Visual Studio tells us
Figure: Trying to test a type that is in a Silverlight class library
SwapperTests.cs(20,13): error CS0012:
The type 'System.Collections.ObjectModel.ObservableCollection`1<T0>' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
Adding that reference is not easy as we will see..
You can try to copy and paste that reference
Figure: PowerCommands for Visual Studio 2010 allow you to easily copy and paste references between projects
but you might get this error
Figure: Error HRESULT E_FAIL has been returned from a call to a COM component.
…because that type is Silverlight specific and the Microsoft test framework doesn't support Silverlight.
BTW:
That's the reason we have the "Microsoft Silverlight unit test framework" which runs tests only in the browser.
This is useless for us cause we want to run tests on the build server and not in the browser
How can we solve this problem? And write tests for the above method?
If you use Collection<T> instead of ObservableCollection<T> then you can write tests around those methods. The Collection type has all methods you need.
ObservableCollection has an additional event for Silverlight ("NotifyPropertyChanged") but because of polymorphism all should be good!
Polymorphism FTW!
Passing in an ObservableCollection is fine, because it implements Collection.
Additionally all events fire under the hood, because it is still an ObservableCollection
No comments:
Post a Comment