We have a callout to an external webservice that requires retrieving some data from the database via SOQL and then issuing an HTTP GET request, and performing various logic based upon the response. Trying to make our unit tests as robust as possible, we try to always create test data from within the unit tests. However, it seems that creating test data within a unit test, and then trying to do a callout, even when using HttpCalloutMock and Test.startTest() and Test.stopTest() will still throw an exception.
While we could use some hard-coded values in the callout unit-test, we'd really prefer not to, as we'd like to have our tests cover as much of the end-to-end as possible, including retrieving the data from the database (which won't exist unless we create it from within the unit test).
We could separate the logic out into multiple unit tests, one for testing the retrieving of the data, and another for testing the callout mechanism, but I'd worry there may be logic branches that rely on not only data in the database, but also certain HttpResponses that may be hard to traverse without muddying-up the actual non-test code.
Here is a very much simplified example that shows the problem.
Callout Class:
public class CalloutClass {
public static HttpResponse getInfoFromExternalService(Id myCaseId) {
Case myCase = [SELECT Id, Account.Integration_Key__c FROM Case WHERE Id = :myCaseId LIMIT 1];
HttpRequest req = new HttpRequest();
req.setEndpoint('http://api.salesforce.com/foo/bar?id=' + myCase.Account.Integration_Key__c);
req.setMethod('GET');
Http h = new Http();
HttpResponse res = h.send(req);
return res;
}
}
And the HttpCalloutMock Class:
@isTest
global class ExampleCalloutMock implements HttpCalloutMock{
global HttpResponse respond(HTTPRequest req){
HttpResponse res = new HttpResponse();
res.setStatus('OK');
res.setStatusCode(200);
res.setBody('GREAT SCOTT');
return res;
}
}
And the TestClass:
@isTest(seeAllData=False)
private class ExampleCallout_Test{
static Case getTestCase(){
Case myCase = new Case(Subject = 'Test');
insert myCase;
return myCase;
}
static testMethod void shouldBeAbleToGetData(){
Case myCase = getTestCase();
Test.startTest();
Test.setMock(HttpCalloutMock.class, new ExampleCalloutMock());
HttpResponse res = CalloutClass.getInfoFromExternalService(myCase.Id);
Test.stopTest();
}
}
And here is the result:
15:30:18.239 (5239722000)|EXCEPTION_THROWN|[45]|System.CalloutException: You have uncommitted work pending. Please commit or rollback before calling out
I'm curious if perhaps I'm missing something, if this is a bug, or is it by design to not allow setting up test data when performing a mocked callout? If there are any creative solutions or workarounds I'd love to hear them as well. :)
Attribution to: Mikey
Possible Suggestion/Solution #1
One option, although not ideal, would be to use @isTest(SeeAllData=true) rather than creating the Case in your test case.
You can't make callouts once you have made changes to the database (in this case the Case insertion proceeds the callout). It seems like this applies to test case setup as well even though it occurs prior to the Test.startTest().
Another option would be to make the mock callout in an @future method and invoke this future method within the Test.startTest() and Test.stopTest(). Updated - This doesn't resolve the issue (at least if the future method is defined in a test class). The CalloutException still occurs with the future method appearing at the bottom of the stacktrace.
To save others the effort, the test data mixed mode DML solution of wrapping the setup code in System.runAs(user) { ... } doesn't help either. Thought it was worth a long shot, but it didn't help.
For reference, the forum post Test method custom setting and callout - Uncommitted work pending covers much the same question. They ultimately reference another post by Bob Buzzard with the suggested resolutions:
You can't make callouts, HTTP or otherwise, once you have made changes to the database. You either need to commit the transaction, make the callout prior to any database changes or move your callout to an @future method.
Ideas: Allow loading test data prior to callout testing is worth promoting.
Attribution to: Daniel Ballinger
Possible Suggestion/Solution #2
The exception is occurring because you are executing a DML operation (insert of Case) before making the mock http call.
In a non-test implementation, to get around this, the http callout would be done in a @future method, so it happens asynchronously, not in the same context.
In this case, since you are mocking the http response, you don't really seem to need to insert the case before making the http call out.
Try getting rid of the getTestCase() method which is creating a test. Instead in your CalloutClass just add an exclusion to the query for Test.isRunningTest(). You're returning a mock response in any case.
Attribution to: techtrekker
Possible Suggestion/Solution #3
This is especially a problem if you have a trigger that calls a future method which makes the callout. The insert needed to fire the trigger will cause the unit test to fail.
Attribution to: David
Possible Suggestion/Solution #4
I've just come across this defect as well. My solution was to modify the callout method to take parameters for the various fields I need rather than rely on sobject data. I also modified the method to be public so that I could call it from the test class. Although not ideal, it allows me to get around the uncommitted exception.
Attribution to: James Loghry
Possible Suggestion/Solution #5
The workaround I used is to manually keep track of the mock response, and call the respond method on that instead of Http.send when running a test.
In your callout class it would look something like:
public class CalloutClass {
public static HttpCalloutMock mock = null;
public static HttpResponse getInfoFromExternalService(Id myCaseId) {
Case myCase = [SELECT Id, Account.Integration_Key__c FROM Case WHERE Id = :myCaseId LIMIT 1];
HttpRequest req = new HttpRequest();
req.setEndpoint('http://api.salesforce.com/foo/bar?id=' + myCase.Account.Integration_Key__c);
req.setMethod('GET');
if (Test.isRunningTest() && (mock!=null)) {
return mock.respond(req);
} else {
Http h = new Http();
return h.send(req);
}
}
}
and in the test you would replace the Test.setMock by
CalloutClass.mock = new ExampleCalloutMock();
It's somewhat intrusive, and would hide cases where there is real DML being done before a callout. But it least gets the test to work pending a better solution.
Attribution to: Jelle van Geuns
Possible Suggestion/Solution #6
I've been able to get around
(a) the 10 callout limit, and
(b) the problem of calling out then using DML in a loop.
If you can possibly use a Batch Apex class to process these, you can login if necessary in the start() method, make one callout each in the execute() method, and process anything further in the finish() method.
In order to make callouts, you'll need to add Database.AllowsCallouts after the Database.Batchable<> keyword in the class definition. In order to access a variable throughout each of the iterations from start, through execute, to finish (like an authToken), you'll need to add Database.Stateful as well.
Usually you can only instantiate a batchable job with a database query, but you can also create a CustomIterable and a CustomIterator to facilitate something different, like a list of custom Apex Classes or a list of SObjects that haven't been inserted yet.
Attribution to: MayTheSForceBeWithYou
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/3486