Help us improve Gearset
Welcome to the Gearset feedback forum. We love getting feedback from our users on how we can make Gearset even better.
Post your ideas and vote for others – let us know what’s important to you. We’re keen to hear about product improvements, new features, and bug fixes alike. We check this forum regularly and will keep ideas updated with their current status. If you need any further support, please contact us at team@gearset.com.
-
Allow run tests not only by specific name but by regex
We have a lot of tests and it takes about 2 hours to run them all. But we also have some small services almost completely isolated and which have a specific test class name convention. Currently, we're using ant to specify which exactly we want to run on these services build, so we don't have to wait for 2 hours to deploy a small fix to an isolated service.
1 vote -
Ability to have Tests to Run during Validation to default to Unchecked all
Ability to have Tests to Run during Validation to default to Unchecked all vs all checked (even before they finish loading into the component). We often validate with only a few tests or predefined group of test classes that we input into 'Specify Tests to run' and if a user inputs those test classes in the text area before all the Tests populate above in the list, it will include all of the ones available. It defaults to checked all and they need to remember to uncheck them or to wait for them all to load which can take awhile…
1 vote -
2 votes
-
Give Permissions to Edit Automated Job Settings
Adding a feature to give users permissions to edit & delete Automated Test Jobs would be great. Today I had to hunt down a colleague to be have him edit his job when all I had to do was change the schedule. This feature would have saved a lot of time.
2 votes -
Support "Test Suites" for CI
Hello, Could we make a suggestion for an enhancement? For CI Unit Test jobs, could we have a Test Suite option?
2 votes -
Provide individual class code coverage statistics
Running tests displays overall org code coverage... it would be cool if you could provide individual class code coverage statistics as well, so we could get a good idea of what classes / triggers need attention
31 votesThanks for the suggestion. We’ve added this to our investigation list. I’ll keep you posted with updates on this status as we progress.
Thanks,
Jason. -
Add a `Weekly` cadence to the test runner
I need to run my own tests (ie no namespace) daily as those should never fail and if they do I need to know
For namespace tests, I just need to run them weekly, primarily to reset the "invalid" flag on apex classes that can be tripped by trivial changes. I know some will fail as we have some huge apps installed and my understanding is that it's normal for dome of those managed tests to fail.
So I would only want to run them weekly to reduce the noise from the daily failure email. Just run those on Saturday.
6 votes -
Automated User Test Suite Integration
Such as Selenium and/or Cypress.io
2 votes -
Display which apex triggers have low code coverage if a deployment fails
It would be great if Gearset can surface which Apex trigger has 0% code coverage when a deployment fails.
9 votes -
Test job triggered by CI job
Test jobs are only configured on time basis. When developer commit some changes and it will be deployed, but tests will be done on a time basis in 2 hours for example, so he should wait to know weather tests are passed or not. Or ask the release manager to run tests manually. So, this feature is must have improvement.
1 vote -
Provide a way to get the debug logs of failing tests
Sometimes my tests are failing when they run during the automated run at night, but, when I log in and run the tests manually, they pass. I can see the failure stack trace, but I was wondering if there is any way to keep/view the debug logs from the failed tests so I can try to understand why they fail at night, but work during the day?
4 votes -
Specify tests to run on the test monitoring jobs
Some of my orgs have many tests, and I don't always want to run all of them on a daily basis. Being able to specify which tests are run daily would be great.
2 votes -
Provide option to disable parallel apex testing in Scheduled Tests
Scheduled Test runs can fail due to UNABLE_TO_LOCK_ROW errors. This is due to what amounts to a bug in SF: accessing public custom settings in tests which are run in parallel can cause deadlocks. Really, the tests ought to be isolated from each other, but they are not. See:
The workaround in SF is to disable parallel apex testing.
If Gearset could do that during the scheduled test run, it would prevent false test failures.
I guess I could change the option on the SF org, but sometimes parallel testing is useful, so I wouldn't want to disable it…
6 votes
- Don't see your idea?