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

Generate test by fuzzing for methods with no parameters #511#515

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
Markoutte merged 1 commit intomainfrompelevin/this_instance_fuzzing
Jul 14, 2022

Conversation

@Markoutte
Copy link
Collaborator

Description

This PR resolves several issues:

  • This instance now created with any public constructor. Reflection is used only if there's no another ways to createthis instance
  • ModelProvider changed its signature to provide a sequence. This is needed to supply values lazily (for example, generate first 10 values and take random)
  • For methods without parameters fuzzer will generate models to changethis instance
  • No more fallback for a regular value generating. Thus, fuzzer doesn't generate test using reflection anymore (except case withthis instance)

Fixes#511

Type of Change

  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Automated Testing

org.utbot.framework.plugin.api.ModelProviderTest

Manual Scenario

Test methodfoo from this example:

packagecom.company.objects;publicclassTestThisInstance {MyObjectvalue;TestThisInstance() {}TestThisInstance(intvalue) {this.value =newMyObject();this.value.setField(value);    }publicbooleanfoo() {if (value.getField() <100 ||value.getField() ==102) {returntrue;        }returnvalue.getField() %2 ==0;    }}classMyObject {privateintfield;publicintgetField() {returnfield;    }publicvoidsetField(intfield) {this.field =field;    }}

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
  • All tests pass locally with my changes

@MarkoutteMarkoutte added the comp-fuzzingIssue is related to the fuzzing labelJul 13, 2022
@MarkoutteMarkoutte requested a review fromdtimJuly 13, 2022 08:58
Copy link
Collaborator

@dtimdtim left a comment

Choose a reason for hiding this comment

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

There are a couple of minor comments, but generally looks OK.

fallbackModelProvider.toModel(methodUnderTest.clazz).apply {
ObjectModelProvider { nextDefaultModelId++ }.withFallback(fallbackModelProvider).generate(
FuzzedMethodDescription("thisInstance", voidClassId,listOf(methodUnderTest.clazz.id), constantValues)
).take(10).shuffled(Random(0)).map { it.value.model }.first().apply {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Are you purposely using the fixed seed here?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

Yes, fuzzer should randomize but be reproducable for same method

* @param index of the parameter in method signature
* @param value fuzzed values
*/
classFuzzedParameter(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this class be a data class?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

IMO, data classes creates hashCode/equals/toString that aren't necessary in most cases

coverage= concreteExecutionResult.coverage,
testMethodName= testMethodName?.testName,
displayName= testMethodName?.displayName
displayName= testMethodName?.takeIf { hasMethodUnderTestParametersToFuzz }?.displayName
Copy link
Collaborator

Choose a reason for hiding this comment

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

If I understand this code right, we will not have display name for tests without parameters at all to avoid explicit "this" argument in the name?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

Yes, it's true

@MarkoutteMarkoutte merged commitd3b10e2 intomainJul 14, 2022
@MarkoutteMarkoutte deleted the pelevin/this_instance_fuzzing branchJuly 14, 2022 08:42
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@dtimdtimdtim approved these changes

Assignees

No one assigned

Labels

comp-fuzzingIssue is related to the fuzzing

Projects

Archived in project

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Generate test by fuzzing for methods with no parameters

3 participants

@Markoutte@dtim

[8]ページ先頭

©2009-2025 Movatter.jp