Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix: Non-ASCII test names being escaped when creating run configurations#8838

Open
chika3742 wants to merge 1 commit intoflutter:mainfrom
chika3742:fix-non-ascii-test-name-escaped
Open

fix: Non-ASCII test names being escaped when creating run configurations#8838
chika3742 wants to merge 1 commit intoflutter:mainfrom
chika3742:fix-non-ascii-test-name-escaped

Conversation

@chika3742
Copy link

@chika3742 chika3742 commented Feb 28, 2026

StringUtil.escapeProperty() was incorrectly applied to test names in CommonTestConfigUtils.findTestName(), converting non-ASCII characters (e.g. Japanese "テスト") to Unicode escape sequences. This caused flutter test --plain-name to receive an escaped string that did not match the actual test name, preventing the test from running.

Fix by removing the escapeProperty() call, which is intended for .properties file encoding and is unnecessary here.

fixes #7985


  • I’ve reviewed the contributor guide and applied the relevant portions to this PR.
Contribution guidelines:

StringUtil.escapeProperty() was incorrectly applied to test names in CommonTestConfigUtils.findTestName(), converting non-ASCII characters (e.g. Japanese "テスト") to Unicode escape sequences. This caused `flutter test --plain-name` to receive an escaped string that did not match the actual test name, preventing the test from running.

Fix by removing the escapeProperty() call, which is intended for .properties file encoding and is unnecessary here.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly resolves an issue where non-ASCII test names were improperly escaped, preventing tests from running. The refactoring of test name extraction logic into a separate, testable method is a positive change for code quality. My review includes suggestions to further improve the new code by adhering to the repository's style guide, specifically by using java.util.Optional to avoid returning null values, which enhances null safety.

Comment on lines +137 to 143
@Nullable
public String extractTestName(@NotNull DartCallExpression call) {
final DartStringLiteralExpression lit = DartSyntax.getArgument(call, 0, DartStringLiteralExpression.class);
if (lit == null) return null;

final String name = DartSyntax.unquote(lit);
if (name == null) return null;

return StringUtil.escapeProperty(name, false);
return DartSyntax.unquote(lit);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

According to the repository style guide (line 48), java.util.Optional should be used for return types that may be empty to avoid returning null. This new method is a good place to apply this pattern. Note that this will require changes at the call sites (which I've commented on separately) and an import for java.util.Optional.

Suggested change
@Nullable
public String extractTestName(@NotNull DartCallExpression call) {
final DartStringLiteralExpression lit = DartSyntax.getArgument(call, 0, DartStringLiteralExpression.class);
if (lit == null) return null;
final String name = DartSyntax.unquote(lit);
if (name == null) return null;
return StringUtil.escapeProperty(name, false);
return DartSyntax.unquote(lit);
}
@NotNull
public java.util.Optional<String> extractTestName(@NotNull DartCallExpression call) {
final DartStringLiteralExpression lit = DartSyntax.getArgument(call, 0, DartStringLiteralExpression.class);
if (lit == null) {
return java.util.Optional.empty();
}
return java.util.Optional.ofNullable(DartSyntax.unquote(lit));
}
References
  1. The style guide recommends using java.util.Optional for return types that may be empty instead of returning null. (link)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since findTestName() returns @Nullable String, wrapping the result in Optional only here is inconsistent.

final DartCallExpression call = findEnclosingTestCall(elt, getTestsFromOutline(elt.getContainingFile()));
if (call == null) return null;

return extractTestName(call);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To accommodate the change in extractTestName to return an Optional<String> (as suggested in another comment), this call site needs to be updated to unwrap the optional and maintain the method's contract of returning a nullable String.

Suggested change
return extractTestName(call);
return extractTestName(call).orElse(null);
References
  1. This change is a consequence of applying the style guide rule (line 48) to use java.util.Optional for nullable return types. (link)

Comment on lines +29 to +30
final String name = TestConfigUtils.getInstance().extractTestName(call);
assertEquals("テスト", name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If extractTestName is updated to return Optional<String> as suggested in another comment, this test will need to be updated to handle the Optional return type. You may also need to add a static import for org.junit.Assert.assertTrue.

      final java.util.Optional<String> name = TestConfigUtils.getInstance().extractTestName(call);
      org.junit.Assert.assertTrue(name.isPresent());
      assertEquals("テスト", name.get());
References
  1. This test update is required to correctly test the extractTestName method after applying the style guide rule (line 48) to use java.util.Optional. (link)

@chika3742 chika3742 marked this pull request as ready for review February 28, 2026 13:26
@chika3742 chika3742 marked this pull request as draft February 28, 2026 14:07
@chika3742 chika3742 marked this pull request as ready for review February 28, 2026 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tests are not run if the name contains Cyrillic(or Korean) characters . When running flutter tests in IntelliJ IDEA.

1 participant