I ran into this while writing unit tests for my org but I simplified it in a developer account to make sure it would happen there.

I have custom object Thing__c. The Name field is autonumber. I wrote the following unit test:

static testMethod void myUnitTest() {
    List<Thing__c> things = new List<Thing__c> {
        new Thing__c(), new Thing__c(), new Thing__c()
    };        
    insert things;
    List<Thing__c> queriedThings = [select name from Thing__c];
    for (Thing__c thing : queriedThings) {
        system.debug('+++ ' + thing.Name);
    }
}

And the relevant log lines are as follows:

+++ C-100000

+++ C-100001

+++ C-100002

So then I add a @testSetup method, and my test class looks in full like this:

@isTest
private class ThingTest {
    @testSetup()
    static void setup() {
        List<Thing__c> things = new List<Thing__c> {
            new Thing__c(), new Thing__c(), new Thing__c()
        };        
        insert things;
    }

    static testMethod void myUnitTest() {
        List<Thing__c> things = new List<Thing__c> {
            new Thing__c(), new Thing__c(), new Thing__c()
        };        
        insert things;
        List<Thing__c> queriedThings = [select name from Thing__c];
        for (Thing__c thing : queriedThings) {
            system.debug('+++ ' + thing.Name);
        }
    }
}

This inserts 6 Things__c records, so they should be named from C-000000 to C-000005, but they're not. Numbering restarts where it started when creating the first record in the @testSetup method. Log shows:

"Name":"C-100000","Id":"a0236000002FskaAAC"

"Name":"C-100001","Id":"a0236000002FskbAAC"

"Name":"C-100002","Id":"a0236000002FskcAAC"

"Name":"C-100000","Id":"a0236000002FskdAAC"

"Name":"C-100001","Id":"a0236000002FskeAAC"

"Name":"C-100002","Id":"a0236000002FskfAAC"

If you don't want the repeated numbers then create it all in the test method and use no testSetup annotation. Just call the method manually in each test method. But this, for me, renders @testSetup not very useful.

Why does this happen? Is this a bug or intended behavior? Is there a way I can use @testSetup and have autonumbering work as I expect it to?

  • Interesting. Seems like a bug. Is this related to salesforce.stackexchange.com/questions/119272/…? – Adrian Larson Apr 26 '16 at 16:01
  • @AdrianLarson it is indeed Adrian. I answered there and thought it would be better to have a more specific question with all the needed info. In that question I didn't mention I was using testSetup. Didn't think it had anything to do. – Pedro Otero Apr 26 '16 at 16:04
  • Yeah this makes it much more interesting. Probably should delete that other question since this one will provide any answers that could have and it didn't have enough information to begin with (as we now know). – Adrian Larson Apr 26 '16 at 16:06
  • 1
    Do you have the Independent Auto-Number Sequence Test Option turned on? – Adrian Larson Apr 26 '16 at 16:07
  • @AdrianLarson Disabled it and works as I expected. But still, shouldn't it work with or without the setting? – Pedro Otero Apr 26 '16 at 16:14
up vote 6 down vote accepted

My hunch is that when you enable Independent Auto-Number Sequence Test Option, the auto number sequence gets reset for every transaction. Since @testSetup runs in a different context, it should be a separate transaction from the unit test. Hence, the unit test itself gets a fresh sequence.

  • Do you still think it sounds like a bug? Because one of the benefits of a \@testSetup method is not having to repeatedly call it and suppose a preset environment before every test. So this issue forces me to either use independent numbering for tests or use \@testSetup. Shouldn't I be able to have both? – Pedro Otero Apr 26 '16 at 16:39
  • @PedroOtero No, on second thought this seems to be WAD (working as designed). – Adrian Larson Apr 26 '16 at 16:53
  • @PedroOtero As for the conflict, you are just going to have to set up all your data in @testSetup if you want to use it. – Adrian Larson Apr 26 '16 at 17:11

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.