Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Field assertions fixes#920

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Damtev merged 6 commits intomainfromdamtev/field_assertions_fixes
Oct 12, 2022
Merged

Field assertions fixes#920

Damtev merged 6 commits intomainfromdamtev/field_assertions_fixes
Oct 12, 2022

Conversation

@Damtev
Copy link
Member

@DamtevDamtev commentedSep 13, 2022
edited
Loading

Description

Fixes for several consecutive bugs with field assertions:

  1. Unnecessary Object type case for variables created with reflection
  2. Missed initial field states for arrays
  3. Unnecessary field state assertions for failed tests

Also, added line separator after single-line block comment.

See corresponding tests behavior in Manual Testing section.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Automated Testing

org.utbot.examples.codegen.modifiers.ClassWithPrivateMutableFieldOfPrivateTypeTest

Manual Scenario

Consider the following code:

publicclassStringRegex {Patternpattern =Pattern.compile("\\d{1,10}\\w");publicStringstringRegex(Stringstr) {if (pattern.matcher(str).find()) {returnstr.substring(0,2);        }else {returnstr;        }    }}

and generate tests for the methodstringRegex with the following settings:[Java, JUnit4, No mocks, 60s timeout, useConcreteExecution = true].

  1. One of the generated test methods contains the following code:
stringRegex.stringRegex(null);Patternpattern1 =stringRegex.pattern;ObjectfinalStringRegexPatternCompiled =getFieldValue(pattern1,"java.util.regex.Pattern","compiled");ClassassertClazz =Class.forName("org.junit.Assert");ClassfinalStringRegexPatternCompiledType =boolean.class;MethodassertTrueMethod =assertClazz.getDeclaredMethod("assertTrue",finalStringRegexPatternCompiledType);assertTrueMethod.setAccessible(true);Object[]assertTrueMethodArguments =newObject[1];assertTrueMethodArguments[0] =finalStringRegexPatternCompiled;assertTrueMethod.invoke(null,assertTrueMethodArguments);

Here the JUnit4 methodassertTrue is invoked using reflection because of variablefinalStringRegexPatternCompiled with typeObject.
But in this example this variable may be safely casted to its typeboolean, and reflection usage for theassertTrue usage would be redundant.

So, expected code:

stringRegex.stringRegex(null);Patternpattern1 =stringRegex.pattern;booleanfinalStringRegexPatternCompiled = ((Boolean)getFieldValue(pattern1,"java.util.regex.Pattern","compiled"));assertTrue(finalStringRegexPatternCompiled);
  1. One of the generated test methods contains the following code:
stringRegex.stringRegex(null);Patternpattern1 =stringRegex.pattern;int[]finalStringRegexPatternBuffer = ((int[])getFieldValue(pattern1,"java.util.regex.Pattern","buffer"));Patternpattern2 =stringRegex.pattern;MapfinalStringRegexPatternNamedGroups = ((Map)getFieldValue(pattern2,"java.util.regex.Pattern","namedGroups"));Patternpattern3 =stringRegex.pattern;ObjectfinalStringRegexPatternGroupNodes =getFieldValue(pattern3,"java.util.regex.Pattern","groupNodes");Patternpattern4 =stringRegex.pattern;int[]finalStringRegexPatternTemp = ((int[])getFieldValue(pattern4,"java.util.regex.Pattern","temp"));Patternpattern5 =stringRegex.pattern;intfinalStringRegexPatternPatternLength = ((Integer)getFieldValue(pattern5,"java.util.regex.Pattern","patternLength"));assertNull(finalStringRegexPatternNamedGroups);assertEquals(0,finalStringRegexPatternPatternLength);

There are no assertions forfinalStringRegexPatternNamedGroups andfinalStringRegexPatternGroupNodes because they have array types and are filtered out from initial states by mistake.

So, expected code is:

stringRegex.stringRegex(null);Patternpattern1 =stringRegex.pattern;booleanfinalStringRegexPatternCompiled = ((Boolean)getFieldValue(pattern1,"java.util.regex.Pattern","compiled"));Patternpattern2 =stringRegex.pattern;int[]finalStringRegexPatternBuffer = ((int[])getFieldValue(pattern2,"java.util.regex.Pattern","buffer"));Patternpattern3 =stringRegex.pattern;MapfinalStringRegexPatternNamedGroups = ((Map)getFieldValue(pattern3,"java.util.regex.Pattern","namedGroups"));Patternpattern4 =stringRegex.pattern;ListfinalStringRegexPatternTopClosureNodes = ((List)getFieldValue(pattern4,"java.util.regex.Pattern","topClosureNodes"));Patternpattern5 =stringRegex.pattern;int[]finalStringRegexPatternTemp = ((int[])getFieldValue(pattern5,"java.util.regex.Pattern","temp"));Patternpattern6 =stringRegex.pattern;booleanfinalStringRegexPatternHasSupplementary = ((Boolean)getFieldValue(pattern6,"java.util.regex.Pattern","hasSupplementary"));assertTrue(finalStringRegexPatternCompiled);assertNull(finalStringRegexPatternBuffer);assertNull(finalStringRegexPatternNamedGroups);assertNull(finalStringRegexPatternTopClosureNodes);assertNull(finalStringRegexPatternTemp);assertTrue(finalStringRegexPatternHasSupplementary);

that contains assertions for these fields.

  1. Actually, the execution above is exception-throwing and breaks after invocation of method under teststringRegex.stringRegex(string);.
    So, all these field assertions are redundant because they will never be invoked, and the last statement of this test method has to be MUT invocation.

Checklist (remove irrelevant options):

  • The change followed the style guidelines of the UTBot project
  • Self-review of the code is passed
  • The change contains enough commentaries, particularly in hard-to-understand areas
  • New documentation is provided or existed one is altered
  • No new warnings
  • New tests have been added
  • All tests pass locally with my changes

@DamtevDamtev added ctg-bugIssue is a bug comp-codegenIssue is related to code generator labelsSep 13, 2022
@DamtevDamtevforce-pushed thedamtev/field_assertions_fixes branch fromab2fd98 to4713374CompareSeptember 16, 2022 09:34
@DamtevDamtevforce-pushed thedamtev/field_assertions_fixes branch 2 times, most recently fromb05acbb toa177d4cCompareOctober 7, 2022 10:17
@DamtevDamtevforce-pushed thedamtev/field_assertions_fixes branch froma177d4c to130f598CompareOctober 7, 2022 13:23
Copy link
Collaborator

@EgorkaKulikovEgorkaKulikov left a comment

Choose a reason for hiding this comment

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

Thank you very much for fixing these problems.

@DamtevDamtev merged commita0738ed intomainOct 12, 2022
@DamtevDamtev deleted the damtev/field_assertions_fixes branchOctober 12, 2022 13:53
AbdullinAM pushed a commit to AbdullinAM/UTBotJava that referenced this pull requestOct 17, 2022
* Used real variable type after field access with reflection if possible* Added missing line separator after single-line block comment* Added missed initial field states for arrays* Removed field state assertions for failing tests
AbdullinAM pushed a commit to AbdullinAM/UTBotJava that referenced this pull requestOct 17, 2022
* Used real variable type after field access with reflection if possible* Added missing line separator after single-line block comment* Added missed initial field states for arrays* Removed field state assertions for failing tests
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@EgorkaKulikovEgorkaKulikovEgorkaKulikov approved these changes

Assignees

No one assigned

Labels

comp-codegenIssue is related to code generatorctg-bugIssue is a bug

Projects

Archived in project

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@Damtev@EgorkaKulikov

[8]ページ先頭

©2009-2025 Movatter.jp