Fixed [NavigationRailDestination]'s label opacity while disabled not being coherent with the icon

[matheus-kirchesch]

Fixing the opacity of the NavigationRailDestination widget label while it is disabled, right now it doesn't get affected by the disabled attribute, which doesn't match the icon that gets affected

• [bug] Appearance of [NavigationRailDestination] while disabled not coherent, the label is ignoring the attribute and not being darkened #132344

I believe this PR should be marked as [test-exempt]

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
• I signed the [CLA].
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is [test-exempt].
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[matheus-kirchesch]

bump

[HansMuller]

This doesn't appear to be needed for the test.

[HansMuller]

It's not clear why this pump is needed? If we need to wait for the NavigationRail to animate into view (I don't think so?) then use pumpAndSettle() and add a comment to that effect.

[HansMuller]

Although highly factored tests are usually a bad idea, a little factoring here wouldn't hurt:

double? defaultTextStyleOpacity(String text) {
  return tester.widget<DefaultTextStyle>(
    find.ancestor(
      of: find.text(text),
      matching: find.byType(DefaultTextStyle),
    ).first,
  ).style.color?.opacity;
}

expect(defaultTextStyleOpacity('Abc'), 1);
expect(defaultTextStyleOpacity('Bcd'), 0.38);

[HansMuller]

It shouldn't be necessary to soften this test to != 1 since we're explicitly setting the opacity to 0.38.

[HansMuller]

If you're having trouble with comparing floating point numbers using the closeTo matcher is preferable:

expect(defaultTextStyleOpacity('Bcd'), closeTo(0.38, 0.01));

[matheus-kirchesch]

Thanks for the tip, will update it

[HansMuller]

LGTM