Fixes #22914 #22917
Fixes #22914 #22917
Conversation
|
@dotnet-policy-service agree |
There was a problem hiding this comment.
Thanks for this PR! This makes a lot of sense and looks good.
Are you able to add a UI test to confirm this works as expected?
This PR has a good example of what a UI test is: https://github.com/dotnet/maui/pull/21250/files It has 2 new tests added which consist of 32 parts:
- the page for the issue in the test app
- the test for appium
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
@mattleibow Working on it! |
PureWeen
added
the
area-controls-general
|
Launching the build again, just applied some small changes in the test adding a couple of pending namespaces and changing the test name. |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| foreach (var elementId in _expectedNullBackgroundColorIds) | ||
| { | ||
| var element = App.WaitForElement(elementId, $"Timed out waiting for {elementId}"); | ||
| var elementBackgroundColor = element.GetAttribute<Color?>("BackgroundColor"); |
There was a problem hiding this comment.
This is not implemented in appium by all the supported .NET MAUI platforms:
System.NotImplementedException : 'BackgroundColor' attribute is unknown for the element. Only the following attributes are supported: [checkable, checked, {class,className}, clickable, {content-desc,contentDescription}, enabled, focusable, focused, {long-clickable,longClickable}, package, password, {resource-id,resourceId}, scrollable, selection-start, selection-end, selected, {text,name}, hint, extras, bounds, displayed, contentSize]
As an alternative, you can use the VerifyScreenshot method. Will create a reference snapshot and the test will compare a new one created every time the test run with the reference one. In that way, can check the BackgroundColor. Other option, is create a Device Tests. Can find some samples accessing the platform control background color here https://github.com/dotnet/maui/blob/main/src/Controls/tests/DeviceTests/Elements/BoxView/BoxViewTests.cs#L29
There was a problem hiding this comment.
I think its safer to use VerifyScreenshot since we need to assert that property changes visually.
How do you take the screenshots for the test, in order to place them in snapshots folders.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| var tapAreaResult = App.WaitForElement(ButtonId, $"Timed out waiting for {ButtonId}"); | ||
| tapAreaResult.Tap(); | ||
|
|
||
| VerifyScreenshot("Issue22914Test.png"); |
There was a problem hiding this comment.
Is not necessary to set the extension.
| Text="Sample label" | ||
| x:Name="Label1"/> | ||
|
|
||
| <Button AutomationId="Tap1Button" |
There was a problem hiding this comment.
It is not necessary but it would be nice to have text on the Button.
| </ContentView> | ||
|
|
||
| <Label HeightRequest="100" | ||
| Background="Green" |
There was a problem hiding this comment.
Here, should use BackgroundColor. If not, after tapping the Button and setting it to null, will not impact to the Background.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/rebase |
Description of Change
Expecting a specific layout type on ViewExtensions for Android and iOS makes impossible to set backgroundColor to null once it has been set
Issues Fixed
Fixes #