Stephen Price wrote:
Hey gurus,
I'm thinking about a unit test that verifies the events raised from
setting properties of viewmodels. I thought the test could load each
assembly in my solution, set each property that has a setter (in turn)
and check how many times the NotifyPropertyChanged event (for
Silverlight UI bindings) and fail the test if it raises more than
once.
The reason I'd like to test this is because we're using a tool called
Notify Property Weaver, which injects the necessary code into the
assembly and wires up the RaisePropertyChanged events. Sometimes
however, it's forgotten and developers add in one anyway. This results
in multiple events being raised. Normally you'd think that not much of
an issue but it has resulted in Ids being generated twice and some
other weird funkiness™ going on.
Just thought I'd throw that out there to see what people think.
Wasting my time testing properties? Maybe a fancy iterative bit of
Reflection magic someone has tucked away, waiting to share with me?
cheers,
Stephen
Heya Stephen,
First off, if you are using the Weaver, it should be obvious from the
implemented interface that properties are wired up, so the programmers
*should* be more careful. Granted that we don't live in the world of should.
One way off the top of my head (I may be wrong) which I believe you
could test this is, as you mentioned, reflection.
Simply add the objects you want to test to an array of initialised
objects, and for each object in the array, use reflection to get a list
of the properties which you can "set". For each of those properties,
create a databinding to a text box, and update the property. Count the
amount of changes on the text box, and if you get anything different to
1 change, you have an issue.
An even better way would just be to subscribed to the propertyChanged
event, and then change each property which has a "setter". When
propertyChanged (or whatever it is) is called, you will be handed a
propertyField string. Simply add these strings to a
SortedDictionary<string, int> where the int has the count. At the end of
the test see which properties are not in the sorted dictionary, and see
which Keys in the sorted dictionary have a value of > 1.
I can't be 100% sure this will work, but off the top of my head it seems
like it would.
Something else you can do is use ILDASM to manually take a look at a few
classes and see if the notify event is been called twice (or not at all).
Good luck,
--
Les Hughes
l...@datarev.com.au
