Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ Draft ] Adding tests for Fluent theme #10385

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dipeshmsft
Copy link
Member

@dipeshmsft dipeshmsft commented Feb 3, 2025

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

@dipeshmsft dipeshmsft requested review from a team as code owners February 3, 2025 05:00
@dotnet-policy-service dotnet-policy-service bot added the PR metadata: Label to tag PRs, to facilitate with triage label Feb 3, 2025
@dipeshmsft dipeshmsft marked this pull request as draft February 3, 2025 05:09
@h3xds1nz
Copy link
Member

h3xds1nz commented Feb 3, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
draft PR metadata: Label to tag PRs, to facilitate with triage Win 11 Theming
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants