[SalesForce] Test execution order issues with Queueable and @future method

Your logic is slightly flawed. All async code can run in to stale data. The difference between Batchable, Queueable, and Future methods is how they're designed to behave. Batchable calls were designed to allow for heavy asynchronous processing. But, it was the only asynchronous code at one point, and it was too "heavy" in terms of resource usage, and had a lot of baggage associated with it. It required a long time to process and was often used only to handle callouts or things that were slightly longer than a normal transaction could handle.

So, next came future methods. Unlike Batchable methods, they were lighter on resources and perfect for doing that job that Batchable was doing before, but much more efficiently. Unfortunately, it was too efficient. You didn't know when the job was done (no Job ID), and it only had a limited amount of space to store data (the reason why it only accepted primitives and collections thereof).

In response to feedback, a third version of asynchronous code was designed: Queueable. It was lighter than Batchable, but it gave you a Job ID and let you store complex data patterns. The lesser resources it used compared to batchable also meant higher limits. Queueable was meant to be a hybrid between the limited future methods and the resource-hungry Batchable interface.

So, to get back to your question: you should always avoid passing in entire SObjects, especially if they may change between serialization and execution. If you need heavy processing, you probably want Batchable, while if you want normal-sized transactions with increased limits, you probably want Queueable. Of course, you can still use future methods if you don't need to monitor the results of the execution, and they'll continue to work for the foreseeable future.

I ran into something similar to what you're describing here. I had all data setup in a testSetup method and committed no DML's in between Test.startTest() and Test.stopTest(), just querying a record and passing that to the data to a web service.

I also confirmed that there were no fresh DML statements by adding a Limits.getDMLStatements() right before the call out, it returned 0. I have scoured the boards and this is the best example that's similar to the behavior I have run into.

I'm certain it's a bug on the Salesforce side, and unfortunately those can take a while to resolve and I need to have this deployed! I came up with a workaround, and I wanted to share it since it may save you (if you're still having the issue) or someone else a lot of misery!

In my mock class that I was calling during the test, I had my sample JSON responses defined as static strings. So I did a tweaked version of a response built in to the call out:

//This is one of the callout functions that I'm using to hit a REST API
global HttpResponse getAllTemplates() {

    HttpRequest req = setupBaseRequest(null);
    req.setEndpoint(baseEndPoint+'/templates');
    req.setMethod('GET');

    HttpResponse res;
    if (Test.isRunningTest()) {
        res = new HttpResponse();
        res.setBody(MyMockClass.templateExampleJSON);
        res.setStatusCode(200);
        res.setStatus('OK');
    }
    if (!Test.isRunningTest()) res = new Http().send(req);
    return res;
}

Here is my mock class (example only):

@isTest
global class MyMockClass implements HttpCalloutMock {
    global static String templateExampleJSON = '{"templateName":"TestName","TemplateId":"12345"}';

    global HTTPResponse respond(HTTPRequest req) {
    HttpResponse res = new HttpResponse();
    res.setStatusCode(200);
    res.setStatus('OK');

    if (req.getEndPoint().contains('/templates')) {
        res.setBody(templateExampleJSON);
    } else {
        res.setStatusCode(400);
        res.setStatus('Bad Request');
    }

    return res;
}

Doing it this way allows my test class to fire correctly. It also allows the actual response to go out when it's not testing. I feel like it's a little bit of a hack; however, it accomplishes my end goal of testing the functionality.