Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add project dependency mutation #368

Merged
merged 19 commits into from
Dec 6, 2021
Merged

Add project dependency mutation #368

merged 19 commits into from
Dec 6, 2021

Conversation

asodja
Copy link
Member

@asodja asodja commented Nov 11, 2021

We generate projects before scenario begins so we don't modify settings.gradle later. And then combinations of project dependencies are applied to the build.

@asodja asodja changed the base branch from master to asodja/android-studio-int-tests November 11, 2021 15:09
@asodja asodja self-assigned this Nov 12, 2021
@asodja asodja changed the base branch from asodja/android-studio-int-tests to master November 12, 2021 08:34
README.md Outdated Show resolved Hide resolved
@asodja asodja force-pushed the asodja/dependency-mutation branch 2 times, most recently from 75a69c1 to 5099b4b Compare November 14, 2021 20:11
@asodja asodja changed the title Add dependency mutation Add project dependency mutation Nov 15, 2021
@asodja asodja removed the request for review from wolfs November 15, 2021 11:08
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
asodja and others added 2 commits November 16, 2021 13:59
Co-authored-by: Lóránt Pintér <lorant@gradle.com>
…tor and ApplyProjectDependencyChangeSetupMutator
README.md Outdated Show resolved Hide resolved
@asodja asodja requested a review from lptr November 22, 2021 08:19
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
import static com.google.common.base.Preconditions.checkArgument;
import static org.gradle.profiler.mutations.ApplyProjectDependencyChangeMutatorConfigurator.APPLIED_PROJECTS_COUNT_KEY;

public class ProjectCombinationsSupport {
Copy link
Member

Choose a reason for hiding this comment

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

Why not have these methods on ProjectCombinations?

Copy link
Member Author

@asodja asodja Dec 1, 2021

Choose a reason for hiding this comment

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

I really like "data only classes". So classes that don't have any logic in there (except maybe trivial creator methods), since that makes other code easier to test. Also having such code in classes then you soon end with multiple similar static methods and class gets bloated and harder to read.

This particular logic is already a bit complex so I decided to move out of it. I left the supported class due to what is written on next comment. Let me know what you think there.

Copy link
Member

Choose a reason for hiding this comment

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

I agree that we shouldn't have instance methods mutating state, but this is something different. This is a static factory method that belongs to ProjectCombinations. I don't see any benefit in moving it out to a separate class.

Copy link
Member Author

Choose a reason for hiding this comment

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

removed support class

import java.util.List;
import java.util.Set;

public class ProjectCombinations {
Copy link
Member

Choose a reason for hiding this comment

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

Why does this belong in a package called support? This is part of the mutators.

If we could merge the two project-dependency-change-related mutators, we could move this to a nested subclass, and that'd look a lot better I think.

Copy link
Member Author

Choose a reason for hiding this comment

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

Mutations package is really huge, and it's hard to find classes there. I created this package so these support classes, that are not mutators, are easy to find. They are still under mutations package.

I will check how easy it is to merge two classes into one.

Copy link
Member Author

Choose a reason for hiding this comment

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

I merged mutator classes into one. Code wise it is probably easier to understand. I also moved ProjectCombinations as a subclass of now one mutator class.

But I kept the support class, that way since it's a bit complex logic and it's much nicer to test that if it is separate. And since it's easier to test that when separate unit, that is a good flag for me that it might deserve a separate class. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

I like that ProjectCombinations is now a nested class. I think that makes this support class even more of an orphan that should be reunited with its folks.

Copy link
Member Author

Choose a reason for hiding this comment

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

removed support class

@@ -47,6 +50,7 @@ class ApplyChangeToAndroidLayoutFileMutatorTest extends AbstractMutatorTest {
def mutator = new ApplyChangeToAndroidLayoutFileMutator(sourceFile)

when:
mutator.beforeScenario(scenarioContext)
mutator.afterScenario(scenarioContext)
Copy link
Member

Choose a reason for hiding this comment

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

I think these tests don't make much sense now. We could make some random change between beforeScenario() and afterScenario() to make it meaningful.

But since this logic of "saving and restoring the original text" happens for every file change mutator, it's not really useful to test it so many times.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe a better option would be to have a method to create the mutator in every test that also calls mutator.beforeScenario() and mutator.beforeBuild()?

Copy link
Member Author

Choose a reason for hiding this comment

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

I see your point., but there are actually tests with: reverts changes when nothing has been applied :D. So they already tested before that there is no action.

I left them for now, since they are there, do you think I should delete them to not continue with that pattern in future?

@asodja asodja requested a review from lptr December 1, 2021 12:42
Copy link
Member

@lptr lptr left a comment

Choose a reason for hiding this comment

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

LGTM, the remaining comments are about code style that we can discuss separately if we want.

@@ -1,12 +1,15 @@
package org.gradle.profiler.mutations.support
Copy link
Member

Choose a reason for hiding this comment

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

Shall we move this to a level higher? Or merge the test into ApplyProjectDependencyChangeMutatorTest?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@@ -123,5 +139,78 @@ public ProjectCombinations(List<String> projectNames, Set<Set<String>> combinati
public Set<String> getNextCombination() {
return combinations.next();
}

public static ProjectCombinations createProjectCombinations(int numberOfRequiredCombinations, int appliedProjectsCount) {
Copy link
Member

Choose a reason for hiding this comment

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

No need for this to be public (we typically use default visibility + @VisibleForTesing for methods that need to be available from tests). The methods can also be part of ApplyProjectDependencyChangeMutator itself, though that might be a question of taste.

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed public and add annotation

… also limit scope of ProjectCombinations creator method
@asodja asodja merged commit bee76c5 into master Dec 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants