I have two apex classes that I am trying to push to production from a sandbox. When I go to validate the change set, it fails on the code coverage part saying that the code coverage is 50% and needs to be 75%. Both of the classes have well above 75% code coverage as one class is at 100% and the other is at 95% from one of the test classes that I wrote within the sandbox. Is there something that I am missing here?
By default all local tests are run during deployment, all custom code your company written (doesn't run tests from installed managed packages. Because they're likely to fail on your required fields and these fails won't stop your deployment).
If you understand what you're doing and are under time pressure to deploy it - you can use the "run specified tests" option & list the test classes. As long as they all have 75% and all triggers being deployed have at least 1% coverage - it'll work. It'll also be quicker. You can do it in the changeset deployment UI as well as in sfdx deploy command options.
But it's a bit of "pro" move, I wouldn't do it unless you have some CI setup and something runs all tests in a sandbox from time to time. You could deploy without realising you've broken functionality you thought is unrelated. It's bit like deploying a new required field or validation rule - "what could possibly go wrong", it's just config, tests don't need to run... boom, headshot.
Proper way to do it would be to refresh sandbox from prod, deploy your code there, run all tests, keep investigating until you bring whole org back to 75%+ and then deploy that.
Related
I have set up a GitHub action that validates code changes upon a pull request. I am using the Salesforce CLI to validate (on PR) or deploy (on main merge).
The documentation gives me several options to determine testing for this deploy.These options are NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg. I am currently using RunLocalTests as so:
sfdx force:source:deploy -x output/package/package.xml --testlevel=RunLocalTests --checkonly
We work with some big orgs whose full tests take quite a while to complete. I would like to only RunSpecifiedTests for validation but am not sure how to set up my GitHub action to dynamically know which tests to pull in. I haven't seen anything in the CLI docs to determine this.
There really isn't a way to do this with 100% reliability. Any change in Apex code has the potential to impact any other Apex code. A wide variety of declarative metadata changes, including for example Validation Rules, Lookup Field Filters, Processes and Flows, Workflow Rules, and schema changes, can impact the execution of Apex code.
If you want to reduce your test and deployment runtime, some key strategies are:
Ensure your tests can run in parallel, which is typically orders of magnitude faster.
Remove any tests that are not providing meaningful validation of your application.
Modularize your application into packages, which can be meaningfully tested in isolation. Then, use integration tests (whether written in Apex or in some other tooling, such as Robot Framework) to validate the interaction between new package versions.
It's only this last that can provide you real ability to establish a boundary around specific code behavior and test it in isolation, although you'll always still need integration tests as well.
At best, you can establish some sort of naming convention that maps between Apex classes and related test classes, but per the point above, using such a strategy to limit test runs has a very real possibility of causing you to miss bugs (i.e., false positives).
My company hired an agency to create an MQL salesforce object. Its constructed from an Apex class with various triggers.
We no longer have a need for it, and as the standing saleforce admin, there is none at the company who knows Apex. I'm taking classes to learn it, but wanted to check in and see how I can deprecate the object from salesforce by archiving/deleting (or even just commenting out the code) to push the update to production.
Does anyone have insight into how to go about doing this? All of the courses I've taken are basic understanding of Apex and how to write small triggers, classes and queries. The agency who built the class left 0 documentation on its code.
You can't write code in production so whatever you'll try to do - will have to be done in sandbox, tested and then deployed.
There's a way to do a "destructive deployment" and really delete it but you'll need programming tools (VSCode, Eclipse IDE or Ant + Migration Tool). It's bit advanced topic, I'd suggest you hire a dev ;) or try to just comment them out.
In sandbox you can comment out the body (bodies?) of triggers and classes. You shouldn't kill whole file, leave some empty skeletons like
public with sharing class MqlGenerator{
/* kill everything
*/
}
trigger MqlTrigger on MQL__c (after insert){
/* kill everything
*/
}
Of course if there's trigger on Account and it does 10 things, only 2 of them relate to MQL then don't comment everything out ;) It'll be bit of trial and error for you, depends how clean the code is.
You will have to touch triggers, normal classes and likely unit tests too because if they did decent job - there will be tests that verify these triggers do something and now these tests will start to fail.
Add the files to changeset as you go (you do changesets, right? Doesn't sound like you deploy with Git+SFDX for example). From time to time run Apex Classes -> Compile all classes and run unit tests. Some manual testing wouldn't hurt too. If you are unsure what's left you can click on MQL's fields, there's "Where is this used?" button. Or even try clicking delete & repeating until it succeeds ;)
After you deploy this changeset...
If the MQL__c has no triggers (for example it is created in Account updates but itself doesn't have triggers), you might actually be able to delete the object. If there are related triggers, workflows etc SF will stop you. The only way to really delete it would be to run this destructive deploy. It's possible without installing anything, use the link I included and for example workbench would let you make a deployment. But it's bit "pro", if you're unsure start with commenting stuff out and maybe leave the empty skeleton until you're more comfortable. You can always hide the object's Tab, remove right to Read the object and it'll disappear from listviews, reports... it'll be an eyesore only for sysadmins.
If object has to stay around but the data storage is significant you could try truncating the object. If it gives you trouble - Data Loader, export all records (just IDs), then delete. Maybe even with hard delete option so you skip recycle bin.
I am working on a new project where the client's pre-existing production code has a low coverage of 72% thus not allowing me to deploy any work done in the Sandbox.
Error:
Code Coverage Failure
Your code coverage is 72%. You need at least 75% coverage to complete this deployment.
Does anyone have recommendations as to how to increase code coverage?
Compile all classes in production
Run all your unit tests (local ones, no need to run tests that come with managed packages)
Go to Developer Console, Query Editor, tick at the bottom the Tooling API checkbox
Run this query
SELECT ApexClassorTrigger.Name, NumLinesCovered, NumLinesUncovered
FROM ApexCodeCoverageAggregate
ORDER BY NumLinesUncovered DESC
LIMIT 10
It should give you a good idea which classes/triggers are least covered. Some of these will be quick wins, time spent on creating/improving their tests will give you best results in oveall coverage. I mean it's better to spend 1h fixing class that has 60 out of 100 lines covered than class that has 2 out of 4 covered. Work in sandbox till you're > 75%
(there's a chance your sandbox is outdated and somebody created validation rules, required fields etc straight in production without deploying... that's why I asked to compile & run all tests in prod)
If there are classes/methods that aren't used anymore and it'd be safe to delete them - you can't do it with changeset, you need a special destructive deployment. For now you could comment them out and deploy that version. Just check if this is beneficial for you (I mean of course it's good to get rid of old code, easier maintenance... but if it happens to be well covered with tests you'll shoot yourself in the foot)
Add the created/updated test classes to changeset and you should be able to deploy it to prod.
We are having an issue , where when we run all tests we see some classes repeated. These classes that are repeated are actually incorrectly labeled classes.
Example: Class A and Class B. Run all tests and code coverage shows that Class A has 90% coverage and Class A has 55% coverage.
We believe this is breaking our ide, anyone know how to resolve this?
I have tried clearing the test cache (Setup > Develop > Apex Test Execution > View Test History > Clear Test Data with no change. As well i tried commenting out code that may have called the other class, still no luck.
Interestingly enough this 'bug' is present across our ide's ...dev console, welkins suite, force.com ide... Trying to pin down the cause.
It is present in all the IDE's is because it's also present in your actual Salesforce instance.
Be more specific.
Apex tests run on a server. If you do not have enough coverage you are not allowed to deploy. You probably need to add some tests to the code you'v added to the org. This could also be indication that something else is broken.
For a Website which is made using angular js , our organization used protractor as the tool to automate test cases.
Our organization has come up with a new tool named 'HipTest' to manage test cases automation.
How to integrate protractor test cases with HipTest. I went to following links but was unable to fetch some useful information.
https://docs.hiptest.net/automate-your-tests/
https://github.com/hiptest/hiptest-publisher
Can Anyone help me how to start ?
I'm one of the main contributor or hiptest-publisher, so I should be able to help you.
The quick way to start with hiptest-publisher is to download the bootstrap of the tests from Hiptest (under the automation tab, you will have a "Javascript/Protractor" link).
You will get a zip file with four files (you should add all of them to your version control system, alongside the code of the application you are testing):
- one for the configuration of hiptest-publisher to use the command-line tool
- one for all the tests (you can split them later on, using the --with-folders option in the config file)
- one for the action words: that's the place where you will do the automation
- one for storing the status of the action words you exported (which is used with hiptest-publisher to see which action words have been updated since the last update)
Once the action words are implemented, the test files generated can be integrated in your test suite like any other Protractor test.
On the Hiptest side itself, the only requirement you have is that your tests should only be written using action words only. From what I understand from your post, you do not work directly in Hiptest yourself and you only manage the automation part (or did I get that wrong ? )
For pushing the execution results back to Hiptest, the principle is pretty simple:
- create a test run dedicated to the CI
- run the command "hiptest-publisher --config-file --test-run-id " before the tests (so only the tests inside the test run are executed, you do not want to run a test that someone is currently writing to be executed on fail of course)
- run your tests
- run the command "hiptest-publisher --config-file --push " to push the results back to hiptest.
Note that those two commands (including the test run ID) can be found directly inside Hiptest, from the "Automate" button in the test run.
If you have an Hiptest account, you can contact us directly on the chat, that might be easier to help you through the process.
Ho and I have a recording of the last webinar I made about automation, I guess you could find some useful information there too :)