Add Support for Test Plans

[iteracticman]

Resolves [NO_ISSUE]

Short description 📝

Tuist has no support for Test Plans yet, but we need it to be able to adopt it for our project, so I implemented it.

Solution 📦

I tried to not introduce any breaking changes and keep the solution as simple as possible.

Implementation 👩‍💻👨‍💻

• Add ProjectDescription.TestPlanList and add it to ProjectDescription.TestAction
• Add ProjectDescription.TestAction.testPlans factory method to create Test Actions that have Test Plans instead of Test Targets and restructured initializers along the way
• Add TuistCore.TestPlan and extend TuistCore.TestAction as well as TuistGenerator.SchemesGenerator to include Test Plans, if present in Project Description
• Add a very basic test to SchemesGeneratorTests
• Adapt ios_app_with_custom_scheme fixture and test case
• Update documentation
• Update CHANGELOG

[kwridan]

Thanks for submitting this @iteracticman and great first contribution to the project!

I think you covered most of the technical bits needed to get this feature working and should be good to merge with some minor tweaks.

Some additional bits to complete the PR:

• The documentation can be updated to mention the new testPlans attribute (https://github.com/tuist/tuist/blob/master/website/markdown/docs/usage/project-description.mdx#test-action)
• To help us test this and show case the feature, one of the fixtures e.g. fixtures/ios_app_with_custom_scheme can be updated to include a new scheme that leverages a test plan and adding a new line to https://github.com/tuist/tuist/blob/master/features/generate-3.feature#L24 to get the acceptance tests to run the tests of that scheme
• Lastly, the CHANGELOG can be updated to highlight this new feature

Thanks again @iteracticman - feel free to post back if you need a hand with any of those.

[iteracticman]

Thanks @kwridan, everything should be ready now. Please check.

[iteracticman]

new scheme

[kwridan]

Thanks for the updates @iteracticman

[pepicrft]

Thanks for bringing this feature to the project @iteracticman. I left some final comments. I think we can merge once they are addressed 🚀

[pepicrft]

Dumping an idea here... I like that we have now .testPlans... for initializing the TestActions. What about sticking to the same idea when initializing test actions for targets?

let first: TestAction = .testPlans(default: "...")
let second: TestAction = .targets(targets: [])

And I'd add then a deprecation annotation to the public init to nudge people to use the new constructor. When you do that make sure you test that the warning doesn't break the loading of the manifest.

[iteracticman]

I like that. will do.

[iteracticman]

I tried, but it would require me to add two more static functions because we need to support both config: PresetBuildConfiguration and configurationName: String.

It's already quite redundant, so maybe it's better to refactor configuration handling a bit first to get rid of that redundancy?