Ahhh, the old testing styles problem. Welcome to pain city.
We went through this a few months ago when we were developing an
ExtendedDataGrid. There is no simple or a one-size-fits-all solution.
Basically, when your WPF app starts up, your styles will load or you
will manually load them into the Application object. Then, when your
Visuals render the framework will instruct them to apply the styles and
things work as expected.
In unit testing, the Application object doesn't instantiate
automatically, so styles don't load, so Visuals don't have styles
applied. This usually affects execution paths (especially in extended
controls) invalidating the test before you even start. You can manually
create the Application and apply styles yourself, but even this doesn't
guarantee the Visuals will pick them up, or even that the execution path
will be the same as when you run the app normally. Does it hurt yet?
(it should, sorry.)
We tried in vain to find support on this issue, but couldn't find any on
the Google machine. Our fallback position was to write (yet another) UI
Automation framework that we could use to test when running normally
(that was the only way we could guarantee the execution path was the
same as when the user used our apps). We already use (customised) White
and UI Spy, but these alone couldn't cut it (the UIAutomation system
fails to work after a certain point we couldn't ascertain). We still
haven't actually started building our new framework due to time and
budget constraints.
The best we could do is to use human power to test our Visuals in a few
QA cycles. This leaves us open to regression problems but it's better
than nothing.
Finally, we realised that there is unit testing that tests our data and
view models (where you don't care about styles) and there is unit
testing where you want to test the visuals (get the styles in there and
test Windows, Controls, etc). Because execution paths are changed
depending on if and how you inject styling, these seem to work against
each other and you need to isolate into different test runs.
I take the silent response to your email so far as a sign that nothing
has changed to improve the situation. Bottom line is, testing visuals
remains a challenge that has yet to be sufficiently met. I really hope
someone has a magic bullet to shoot that theory down with, but I'm not
holding my breath.
Carl.
Carl Scarlett
Senior .NET/WPF Developer, UX Designer - Genesis Team
IT Applications Delivery | Bankwest
A: Level 5, 199 Hay Street | Perth | Western Australia | 6004
P: (08) 9449 8703
M: 0408 913 870
E: [email protected]
From: [email protected] [mailto:[email protected]]
On Behalf Of Stephen Price <[email protected]>
Sent: Friday, 18 June 2010 10:47 AM
To: ozWPF <[email protected]>
Subject: missing resource
Hey all,
Working on some WPF and have hit something I'm sure is easy but can't
seem to find an answer on.
I've added a style to the main page and put the new style into a
MergedDictionary, it works no problems. Where i've come unstuck is
there's a unit test in another project that creates an instance of the
shell. It now fails as it can't find the resource. I'm puzzled at how I
add it. I tried copying the App.xaml file but it gives errors pointing
to the fact the project doesn't like there being an
ApplicationDefinition.
Just wondering how other people get around this?
cheers,
Stephen
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
________________________________________________________________________
_______
This email has been scanned by the Bankwest Email Security System.
________________________________________________________________________
_______
_______________________________________________________________________________
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.
This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.
We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
_______________________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
