14

I am using the Ant Migration Tool for deployments. While utilizing this tool, all deployments are visible under the Monitor Deployments page. In a client's production instance, they have more than 1200 unit tests currently written. As the tests run, it will tell you if there are any failures or not. These tests take about 45mins to run all the way through. If I see an error in test 100, I would love to just exit out, fix it, and try deploying again rather than waiting the full 45mins for that one error.

So, I don't think this is possible, but can I cancel out of a deploy once I start it?

Improve this question
8
  • 2
    There's an idea here: success.salesforce.com/ideaView?id=08730000000YJPNAA4, so it doesn't look promising...wonder if someone has a clever way of handling it.
    – Peter Knolle
    Mar 29, 2013 at 14:12
  • 1
    I voted for that idea.
    – Mike Chale
    Mar 29, 2013 at 14:51
  • I voted for the idea as well. Thanks Peter. This is not a very nice "feature" in my opinion. If you know you have a failure, just stop deploying and tell the developer to fix it.
    – Jesse Altman
    Mar 29, 2013 at 15:16
  • @PeterKnolle I would say, based on the feedback provided below and your comment, that this isn't available yet. If you post your comment as an answer, I will accept it. Hopefully that can get the Idea more visibility.
    – Jesse Altman
    Mar 30, 2013 at 13:25
  • 1
    Check out the Summer 13 Release Notes, page 231 - na14.salesforce.com/help/doc/en/…
    – Mike Chale
    Apr 19, 2013 at 18:58

3 Answers 3

Reset to default
7

It is not currently possible to cancel a deployment; however, there is a Cancel Deployment idea on the Idea Exchange. Vote for it!

Improve this answer
1
  • 1
    It looks like this is coming in Summer '13. In the Release Notes (na14.salesforce.com/help/doc/en/…), page 231, under Metadata API: Metadata deployments can be canceled while in progress.
    – Mike Chale
    Apr 19, 2013 at 18:56
1

UPDATE: In hindsight, this doesn't seem like a very good idea and is likely unworkable. I'll leave it here in case someone can salvage it or to at least stop them going down the same path.

The idea suggested by Peter in the comments is worth promoting as a native solution provided by Salesforce is probably the only clean solution.

As a more custom solution, how about creating a base class that all unit tests inherit from that would allow you to bypass subsequent tests after the first failure? Something like having a static member on the test class that tracks if there has been a failure. Then check this value at the start of each test to see if it should be run to completion.

I know this isn't ideal as it would require you to modify your existing tests to first check if there was already a failure. Also, it won't address any external managed package tests and won't work between classes.

Actually, the more I think it through the less appealing this idea is. You would need to move all your assertions into the base class so that it could set the static member before potentially failing the actual assertion. Which would muck up the stack traces etc...

Improve this answer
4
  • Well, external managed package tests don't run during a deploy so I am not worried about them. However, I agree that this really isn't very ideal and I don't think it would work correctly (considering I need to mark each class as @isTest which forces the tests to run). Thanks for the idea though! +1!
    – Jesse Altman
    Mar 29, 2013 at 21:09
  • Statics variables are reset between test runs.
    – ca_peterson
    Mar 30, 2013 at 21:47
  • To achieve this kind of inter-test communication, you could manually (not from the code) set a checkbox value on your User record (User object wouldn't need to violate SeeAllData) in your target org when you see that the deployment is reporting a failed test and set up your tests so the first thing they do is check for it and fail if necessary. Or, maybe you could come up with something clever with auto-numbers knowing that their increments live on outside of their tests. Nothing seems too clean, though.
    – Peter Knolle
    Mar 30, 2013 at 23:47
  • Yeah, I pretty much had to abandon the idea once I realized there wasn't an easy way to communicate between the tests.
    – Daniel Ballinger
    Mar 31, 2013 at 1:39
1

This doesn't exactly answer your question, but may address the issue of dealing with deployments to orgs with LOTS of tests. Once an org has that many tests it starts to cause a bunch of pain with deployment and people stop working to create as many tests (at least in my experience).

What I've been looking to try is instead of hosting all the tests in Salesforce, only tests required to maintain code coverage are hosted natively. The rest our hosted in an external repository. Then an automated process checks out the tests and runs them on a scheduled basis. Alternatively, the tests are present in Salesforce but commented out with a flag that would allow an automated script to uncomment and run the test on a scheduled basis. The idea is that you can creates lots of tests without worrying about speed, but still maintain fast performance.

Improve this answer
2
  • This isn't a bad idea if you are doing development in your own org, but for developing in a client org this doesn't seem viable. We can't just store their tests in different locations. We also can only control what goes on in production to a certain extent (Admins can make whatever changes they want straight in prod for instance). Having all of the tests in prod allow us to know when a new workflow rule/validation rule was introduced that broke our tests. I'm also not really sure how you can check out tests and run them without putting them on an org. Thanks for the idea though! +1!
    – Jesse Altman
    Mar 30, 2013 at 12:34
  • IMHO, admins don't run all tests when they make changes. Since this would be a scheduled process it would catch those sort of tests failures quicker (as opposed to waiting until you deploy to find out an admin has broken your test). To run the tests without putting them in the org we'd just be doing a validation only deployment (most likely with ANT which also has convenient tasks for the checkout feature)
    – Ralph Callaway
    Mar 31, 2013 at 19:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .