[SalesForce] Detect if Apex Flex Queue is enabled in an Org

Here's the problem from the docs:

When testing your batch Apex, you can test only one execution of the execute method. You can use the scope parameter of the executeBatch method to limit the number of records passed into the execute method to ensure that you aren't running into governor limits.

Additionally I don't think batch classes are executed from schedulable classes in test classes but I couldn't find that supporting documentation. From my own experience, testing schedulable batch methods only queues the batches while testing the batch method execution actually runs the batch method. So the asserts after your schedulable tests will always fail if they expect a batch job to complete.

Basically, this means you should test the batch and schedulable classes separately. Once you remove the asserts from the schedulable tests cases everything should work fine and it looks like you'll have full coverage.

Also, you only need one '@isTest' line at the top of your test class. I'm also assuming that the schedulable method at the botton of the test class is not a part of that test class but just a mockup of a standalone class used during production. Just in case, here are how the separate classes should be written:

Test Class

@isTest
private class ScheduleBatchTest {
private enum TestCase {
    DatabaseExecuteBatch,
    ScheduleBatch,
    Schedule
}
static void test1() {
    execute(TestCase.DatabaseExecuteBatch);
}
static void test2() {
    execute(TestCase.ScheduleBatch);
}
static void test3() {
    execute(TestCase.Schedule);
}
private static void execute(TestCase tc) {
    Account[] accounts = new Account[] {
            new Account(Name = 'Acme'),
            new Account(Name = 'Nike')
            };
    insert accounts;
    Test.startTest();
    if (tc == TestCase.DatabaseExecuteBatch) {
        Database.executeBatch(new BatchableExecutorTestBatchable());
        Account[] actuals = [select Site from Account where Id in :accounts];
        System.assertEquals(accounts.size(), actuals.size());
        for (Account actual : actuals) {
            System.assertEquals('executed', actual.Site);
        }
    } else if (tc == TestCase.ScheduleBatch) {
        System.scheduleBatch(new BatchableExecutorTestBatchable(),
                'my description', 5, 100);
        //assert batch  job queued here
    } else if (tc == TestCase.Schedule) {
        System.schedule('my job', '0 0 13 * * ?', new ScheduledBatchable());
        //assert scheduled job queued here
    }
    Test.stopTest();        
}

Batch Class:

public class BatchableExecutorTestBatchable implements Database.Batchable<SObject>, Database.Stateful { 
    public Database.QueryLocator start(Database.BatchableContext bc) {
        Database.QueryLocator ql = Database.getQueryLocator([
            select Name from Account order by Name
            ]);
        insert new Account(Name = 'start');
        return ql;
    }
    public void execute(Database.BatchableContext bc, List<SObject> scope) {
        for (SObject sob : scope) {
            Account a = (Account) sob;
            a.Site = 'executed';
        }
        update scope;
        insert new Account(Name = 'execute');
    }
    public void finish(Database.BatchableContext bc) {
        insert new Account(Name = 'finish');
    }
}

Schedulable Class:

private class ScheduledBatchable implements Schedulable {
    public void execute(SchedulableContext sc) {
        Database.executeBatch(new BatchableExecutorTestBatchable(), 100);
    }
}

Let me know if this works.

In case anyone else ever has this problem in the future, you have to contact Salesforce support and (if you don't have Premier Support because you can't submit Apex issues) convince the agent to escalate this for you, explaining you need to remove any ApexToken jobs which are stuck in the queue. These are visible through a query, but not in the UI, and we (users) can't remove them.

SELECT Id, JobType, CreatedDate, Status FROM AsyncApexJob WHERE JobType = 'ApexToken'

Once this was done, the jobs started as expected.

There was a developer forums post which helped identify this issue: https://developer.salesforce.com/forums/?id=9060G000000I4EzQAK