Skip to main content
24 events
when toggle format what by license comment
Jun 5, 2020 at 0:14 answer added Matthew Souther timeline score: 0
Feb 2, 2020 at 18:55 answer added Menachem Shanowitz timeline score: 4
Oct 18, 2019 at 20:41 history protected CommunityBot
Jul 10, 2019 at 14:20 answer added Patlatus timeline score: 8
Jun 28, 2019 at 13:58 answer added AlessioBortone timeline score: 0
Jun 4, 2019 at 16:05 answer added Henk Poell timeline score: 2
May 3, 2018 at 3:23 comment added Ralph Callaway Running into this issue, but only when I started inserting a test user. Inserting other objects worked perfectly fine when performed before the callout and don't result in a callout exception
Sep 14, 2017 at 12:05 answer added Shruti timeline score: 0
Apr 13, 2017 at 12:54 history edited CommunityBot
replaced http://salesforce.stackexchange.com/ with https://salesforce.stackexchange.com/
Jun 23, 2016 at 7:59 comment added Andrii Muzychuk @NSjonas, I have the same problem. Interestingly, it is caused by one type of object. When I insert it - fail. does not insert it - fine (no uncommitted error). Magic... However, this object is from unmanaged package.
Dec 22, 2015 at 20:27 comment added Eric @NSjonas - Did you try the answer below? Please update or close the question out by accepting the answer. Hate to see you architect at "workaround" just because you cannot get it to work. Lets get it done the right way for ya. I also noticed they fixed the error when doing a callout during a batch and that Mock implementation now works correctly in Winter 16
Sep 18, 2015 at 15:29 history tweeted twitter.com/#!/StackSalesforce/status/644896039007330304
Sep 18, 2015 at 7:12 comment added Eric @NSjonas - You answer is below. It is simply moving the mock lines after the test.starttest
Sep 18, 2015 at 6:24 answer added Ajay Dubedi timeline score: 22
Jul 7, 2015 at 16:29 comment added VAIBHAV Before making a callout ensure you do not have any insert/update/delete DML statements. Try to make the callout.
Aug 12, 2014 at 20:07 comment added NSjonas I ended up just bypassing the callout. I'm testing the callout directly in another place so i don't lose any code coverage. just feels hacky...
Aug 9, 2014 at 18:34 comment added GoldenAxe Try to use @isTest(SeeAllData=true), and use an existing foo id (remove the insert of foo from test), if that solve the problem, then the insertion of foo doing something else (maybe a trigger). By the way I have objects that were inserted before the test (like your foo) which didn't had any trigger or something that related to the call out, but yet by insert them the uncommited work pending error produced, if that will be the case the only solution I have found is to use the old method of bypass call out in test --> Test.isRunningtest() (do something else when testing)
Aug 9, 2014 at 9:33 comment added Daniel Ballinger If you capture a debug log when running the test, what was the last thing to occur before the test fails?
Aug 9, 2014 at 0:18 comment added NSjonas @greenstork the code is long and complex (so I'd rather not post and try to explain it) but there are no DML operations before any callouts in "client.bar(foo.Id)"
Aug 9, 2014 at 0:16 comment added NSjonas @KeithC, checked all of those things... still no go
Aug 9, 2014 at 0:14 comment added NSjonas @greenstork sorry i thought that was obvious. client.bar();
Aug 8, 2014 at 22:52 comment added Keith C This pattern works for me. Two things you could check: 1) that there are no callouts made as a side effect of any code before Test.startTest; 2) that there are no updates made before the callout within the bar method. (One example of a "hidden" update would be a class that automatically inserts uninitialised custom settings when a setting value is referenced for the first time.)
Aug 8, 2014 at 22:02 comment added greenstork Can you post your code? When is your callout initiated in code?
Aug 8, 2014 at 21:45 history asked NSjonas CC BY-SA 3.0