-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
Make List of Apex Class Names from Delta Package.xml to Use In Delta Deployment with Test Run #126
Comments
Hi @nickytorstensson ! Thanks for this great suggestion. I open the solution debate. Should we
|
Hi @scolladon
I hope my answers help :-) |
Deciding exactly which tests to run with So, If we "only" need the list of Apex classes from the package.xml, using a tool such as yq, as @scolladon suggested, seems to me like that the best short-term solution. Here is an example of a command to output the list of Apex classes: EDIT: a more robust version would be @nickytorstensson Would that solution meet your need? |
I agree with @mehdisfdc 's comments and offer my own solution as an example for discussion. @nickytorstensson, I am using SGD for the same use case as you've described. I use the
I use this $testList string as the input to the As our testing pipeline matures, we will be selecting tests much like @mehdisfdc suggests: some baseline suites, added/updated tests, or possibly even detecting dependencies in code and running related tests so the usefulness of SGD outputting test class names will diminish. |
Hi all, First, thanks for sharing your input and considerations! I agree, that every team has their own conventions for selecting, which test classes need to run. And that definitely makes it difficult to develop something general, if everyone will not be using it the same way. However, my suggestion does not focus on the individual team's needs, but the general need, which I believe should apply to all teams.
@mehdisfdc, considering that introducing such functionality will likely result in expectations for extended functionality, then I also agree with scolladon, that this should be in a separate command, such that it can scale well. On your examples for getting the apex classes into a variable, I would have to look into that (still a novice user ;-), so would have to install the programs on my Docker image and run some tests) Best, Nicky |
Hi all, I personally prefer the solution using yq.
I propose to document the usage of yq in the README.md using the query designed by @mehdisfdc to show case how to run Specified Test using this method. |
@scolladon, i dont think the solution works!! for fetching the test classes that covers the delta, arent we suppose to fetch the dependencies? and also it should cover the apex triggers as well. Please let me know the take on this if someone implemented the solution to run the test classes from the delta package |
Hi @RohitGagan16, I agree, I still think it is a relevant feature to have, and instead of each user of the plugin doing as scolladon suggests in his latest comment, it would be preferable that it is a feature of the plugin itself. In addition, I see mehdisfdc referred to this issue in 402 |
@RohitGagan16 @nickytorstensson are you referring to compiling a list of the Apex classes in the delta, so that it can be used in a If this is what your referring to, you'll find an example GitHub actions pipeline that does it here:
|
I took mehdisfdc's string and made few changes to meet my requirement so just shareing if anyone also want's to use it.
Example Above string puts all and only the classes and test classes which are mentioned in package.xml. Where as if your org followed naming convention then you can use the above and it will reduce to put mock commits to include it in runspecified test. NOTE: It will not work in case you are using --generate-delta because in that case it will look for files in that folder and only files available in package.xml are available in that folder. |
Great sharing @Ronak-Toshniwal Why do you think it will not work in case we use Based on your work here, the README and this discussion I have been able to come with those jq queries:
Let me know if it helpful, we could create a PR to enrich the README |
Hi, Just fetching the test classes from the delta is not enough. Rather every dependency of the delta componnet needs to fetched and make sure you have dependent test classes for this. That will solve the problem. So the solution specified above by @mehdisfdc / @Ronak-Toshniwal is not enough |
Hi @RohitGagan16 ! I remember us discussing this approach here! I'm not sure it is the right way to solve that problem, following software engineering best practices with proper unit testings would avoid us to have to calculate this dependency graph. We would be able to rely on those simple In order to know what test classes to call to get the minimum coverage we need to deploy just this class would require to have all the coverage, so it would require to run all test with coverage prior to that. And it will require some graph search algorithm implementation (like a shortest path to get 75% coverage for the classes in the package.xml). It is a lot of work where the solution should not be approached by tooling, it should be approached by clean software engineering practices. Maybe we should open a discussion to sum this up and follow our thought there |
Hi @scolladon, so i wanted to add testclass automatically and if we use delta then that file will not be available in delta package and it will throw no source backed component error. hope you got my point. |
I'm not sure to follow here @Ronak-Toshniwal Let's say we have a
We make a change to $ sfdx sgd:source:delta -f "HEAD~1" -d It generates this folder structure:
And this package.xml: <!-- cat output/package/package.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>MyClass</members>
<name>ApexClass</name>
</types>
<version>57.0</version>
</Package> Then we can deploy either using $ sfdx force:source:deploy -x output/package/package.xml
$ sfdx force:source:deploy -p output/force-app What I understand, according to you, it is not be possible to list test classes to run in specified test if they are not present in the sources deployed. It throws So, as the $ sfdx force:source:deploy -x output/package/package.xml -l RunSpecifiedTests -r "MyClassTest" # success
$ sfdx force:source:deploy -p output/force-app -l RunSpecifiedTests -r "MyClassTest" # failure So your point is: when using I played a bit with this and was able to deploy using both package.xml or source folder and specifying test not present in them but in the platform. I created a branch in our playground if you want to play with as well. Everything done here is in that branch $ git clone https://github.com/scolladon/sfdx-git-delta-reproduction-playground.git
$ cd sfdx-git-delta-reproduction-playground
$ git checkout issue/126
$ sfdx force:source:deploy -p force-app # init To generate the delta folder execute this command: sfdx sgd:source:delta -f "HEAD~1" -d Then deploy $ sfdx force:source:deploy -p output/force-app -l RunSpecifiedTests -r "MyClassTest" # with source
$ sfdx force:source:deploy -x output/package/package.xml -l RunSpecifiedTests -r "MyClassTest" # with package.xml I looked around for the |
Is your proposal related to a problem?
It is fantastic, that the SGD generates a delta package.xml, which is used to deploy the delta. However, if the delta package.xml file contains apex classes (and apex test classes), there is no easy way to generate a list of apex classes to use for the RunSpecifiedTest part of a validation run
If the SGD plugin also could generate such a list, it would make it so easy to also run selected tests in a validation run, further enhancing the delta deployment experience.
E.g. the command for running specified tests:
sfdx force:source:deploy --testlevel RunSpecifiedTests --runtests 'MyApexClass1, MyApexClass1_Test, ... '
Describe the solution you'd like
If the SGD command generates the following package.xml file:
Then I want the SGD plugin to also generate a .txt file (e.g. ApexClassNames.txt) or return a string. The file/string should contain the names of apex classes in above package.xml file (both normal classes and test classes), separated by commas.
E.g. content is string with value
MyApexClass1, MyApexClass1_Test, ...
If .txt file, it can be placed in a new folder, name is optional, to be decided.
Describe alternatives you've considered
The alternative is to generate a script, which gets the package.xml file from the SGD method, access the type with name ApexClass and retrieve all members from the section. Not the prettiest solution, and script will vary between each CI/CD developer, who has this need.
The text was updated successfully, but these errors were encountered: