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

Change the implementation of auto generated schemes #2641

Merged
merged 1 commit into from Mar 12, 2021

Conversation

FranzBusch
Copy link
Contributor

@FranzBusch FranzBusch commented Mar 10, 2021

Resolves #2639

Short description πŸ“

This changes the implementation of the auto generated schemes to only pick test bundles that are naming like the target and have a suffix with Tests, UITests or IntegrationTests

Checklist βœ…

  • The code architecture and patterns are consistent with the rest of the codebase.
  • The changes have been tested following the documented guidelines.
  • The CHANGELOG.md has been updated to reflect the changes. In case of a breaking change, it's been flagged as such.
  • In case the PR introduces changes that affect users, the documentation has been updated.

Copy link
Collaborator

@kwridan kwridan left a comment

Choose a reason for hiding this comment

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

This is a great first code contribution @FranzBusch πŸŽ‰

The changes look good! left some minor inline comments (one should hopefully address the test failure). The other CI check is failing on swift format, you can run bundle exec rake style_correct to re-format the code.

Lastly, mind updating the CHANGELOG file to include a new entry for this change.

Thanks

target: targetBTests,
projectPath: projectPath,
testTargetName: "BIntegrationTests"
),
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe we'll need to update the test helper testScheme to allow specifying an array of test target names to cater for the new changes - as in this test case B target will have 3 test targets in its scheme.

e.g.

XCTAssertEqual(
            got.schemes,
            [
                testScheme(
                    target: targetA,
                    projectPath: projectPath,
                    testTargetNames: ["ATests"]
                ),
                testScheme(
                    target: targetATests,
                    projectPath: projectPath,
                    testTargetNames: ["ATests"]
                ),
                testScheme(
                    target: targetB,
                    projectPath: projectPath,
                    testTargetNames: ["BIntegrationTests", "BTests", "BUITests"]
                ),
                testScheme(
                    target: targetBTests,
                    projectPath: projectPath,
                    testTargetNames: ["BTests"]
                ),
                testScheme(
                    target: targetBUITests,
                    projectPath: projectPath,
                    testTargetNames: ["BUITests"]
                ),
                testScheme(
                    target: targetBIntegrationTests,
                    projectPath: projectPath,
                    testTargetNames: ["BIntegrationTests"]
                ),
            ]
        )

(heh re-examing testScheme I can see how it can be confusing in this context πŸ˜…, perhaps a better choice would have been makeScheme)

@@ -90,7 +90,7 @@ public final class AutogeneratedSchemesProjectMapper: ProjectMapping {
} else {
// The test targets that are dependant on the given target.
return project.targets
.filter { $0.product.testsBundle && $0.dependencies.contains(.target(name: target.name)) }
.filter { $0.product.testsBundle && ($0.name == "\(target.name)Tests" || $0.name == "\(target.name)UITests" || $0.name == "\(target.name)IntegrationTests") }
Copy link
Collaborator

Choose a reason for hiding this comment

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

minor: could possibly have a private helper method isAssociatedTestTarget (or something equivalent)

@@ -30,6 +30,16 @@ final class AutogeneratedSchemesProjectMapperTests: TuistUnitTestCase {
product: .unitTests,
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's worth adding another test case to reproduce the scenario you described in the issue to verify the fix addresses it :)

e.g.

ATests > [A, B]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I covered it with my first test case to make sure only the proper targets are picked up. Is that enough for you @kwridan ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

sure that should do it

@kwridan
Copy link
Collaborator

kwridan commented Mar 11, 2021

@all-contributors add @FranzBusch for code

@allcontributors
Copy link
Contributor

@kwridan

I've put up a pull request to add @FranzBusch! πŸŽ‰

This changes the implementation of the auto generated schemes to only pick test bundles that are naming like the target and have a suffix with `Tests`, `UITests` or `IntegrationTests`
@FranzBusch
Copy link
Contributor Author

@kwridan @pepibumur Could you help me in getting this merged. I am a bit lost why the test if failing

Copy link
Collaborator

@kwridan kwridan left a comment

Choose a reason for hiding this comment

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

Thanks for the updates @FranzBusch!

re: the test failure it seems odd, I wouldn't have thought your changes would impact any of the caching features - will run it locally to see what I can find.

@@ -30,6 +30,16 @@ final class AutogeneratedSchemesProjectMapperTests: TuistUnitTestCase {
product: .unitTests,
Copy link
Collaborator

Choose a reason for hiding this comment

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

sure that should do it

@kwridan
Copy link
Collaborator

kwridan commented Mar 12, 2021

Locally running the failing test in question passes on this PR for me - seems we have some sort of environment flake 😞

./bin/fourier test tuist acceptance features/cache-frameworks.feature

cc: @tuist/core

@laxmorek
Copy link
Collaborator

I had a similar issue with cache-frameworks.feature in my last PR. I re-run jobs and it passed. I don't know where was a problem. πŸ€”

Definitely features/cache-frameworks.feature should no pass "randomly".

@FranzBusch
Copy link
Contributor Author

FranzBusch commented Mar 12, 2021

@laxmorek or @kwridan could somebody re-run the job for me?

@fortmarek
Copy link
Member

fortmarek commented Mar 12, 2021

could somebody re-run the job for me?

done @FranzBusch πŸ‘

Hopefully, it will pass now and we shouldfix the test's flakiness soon as it creates a lot of confusion for contributors when they see a test fail when they did not even introduce any changes to that part of the codebase

@laxmorek
Copy link
Collaborator

It passed now. Definitely we must fix it.

@FranzBusch
Copy link
Contributor Author

@kwridan What do I need to do to get this merged? :)

Copy link
Member

@fortmarek fortmarek left a comment

Choose a reason for hiding this comment

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

Thanks @FranzBusch for your contribution!

@fortmarek fortmarek merged commit 2b7423b into tuist:main Mar 12, 2021
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.

Unexpected auto-generated schemes test action
4 participants