[ Draft ] Adding tests for Fluent theme

[dipeshmsft]

Issue Link : #8552

Description

Hello community members, we are working on writing tests for Fluent UI and ThemeMode property, and here is a basic structure of how I am planning to do this and would like to have your suggestions on how we can make this better. It is okay, if there is a completely different approach that should be taken up.

The tests that are present in this PR, can be divided into three parts :

1. ThemeMode Property Tests : In this set of tests, the main aim is to test the initialization of ThemeMode properties on Window and Application classes. It will include initialization of Application and Window, switching ThemeMode, combination Application and Window ThemeMode properties.
2. Fluent ResourceDictionary Tests : In this set of tests, the main aim is to check the correctness of Fluent colors and brushes ( not control brushes ), loading of different Fluent ResourceDictionary, etc.
3. Control Styles UI Tests : These set of tests are meant to test the behavior and default property values of controls when Fluent this is applied. Here are more details on this :
   • First, I have created a copy of all the Fluent colors and brushes, which will be used as the source of truth.
   • In each test, we launch a window with a control ( can have custom values set for the different properties )
   • For each test there is a dictionary, which corresponds to what values all the properties of controls and and different elements in the template of the control should have, and we verify these values by matching them with the values specified in the dictionary.
   • To avoid redundancy, there is a base ( default ) dictionary for a control, where the property values correspond to Fluent default values for that control.
   • For subsequent tests ( like disabled button, mouse over, Background = Red ) we have separate dictionaries which have a subset of the values defined in the base dictionary. We combine the base dictionary with the dictionary for the current test and use that to verify the different properties of the control in that state.

From the approach that we have followed here, it may be better to put these tests under Integration Tests, but before that, I want your opinions on what limitations we can face with the above approach, or if there is some other approach that we can take to write these tests in a better fashion.

/cc @h3xds1nz @hughbe @JeremyKuhne @ThomasGoulet73 @miloush @lindexi @batzen

Microsoft Reviewers: Open in CodeFlow

[h3xds1nz]

A bit of off-topic: The lucky test failure in debug is pretty much what #9906 was about by the looks of it, and I stand by what I said, that this should be queued on the app thread.

[JeremyKuhne]

Fields really should come first, followed by auto-properties and properties. When editing code whatever is below your current edit is likely to not compile, which makes editing much more difficult when these are at the bottom of the file.

[robert-abeo]

Regions are not really used in modern code. Makes navigation more of a pain.

[robert-abeo]

Personally, I think the control-level tests should be done visually. We should capture and compare bitmap images in various states.

The WinUI design team would sign-off on the correct images.