I am writing a test class for a utility class for inserting PushTopics.

Despite explicitly setting @isTest(SeeAllData=false) on my test class, I am getting a System.DMLException because of a duplicate name. This only happens when I have a PushTopic inserted into the org with the same name prior to running the test. Here is the exception I get.

System.DmlException: Insert failed. First exception on row 0; first error:
DUPLICATE_VALUE, A PushTopic with this name already exists. Please choose a 
different name

What's extra weird is that when I query for it by name in my test class, nothing is returned...as expected with SeeAllData set to false. Then when I try to insert a PushTopic with that name, it errors stating that it's a duplicate.

Am I missing something here or is this a platform bug?

  • 2
    Does it still occur if you appending something like string.valueof(system.now()) to the PushTopic name in the test case? This would help distinguish between a bug in SeeAllData or something else causing the duplicate value. Commented May 30, 2013 at 21:36
  • Yeah, I did just that. No duplicate. I'm 99% sure this is a bug. Commented May 31, 2013 at 1:16
  • @DougB, this will be the standard PushTopic object rather than a custom object. Commented May 31, 2013 at 1:45
  • Ah yeah - and I guess the fact that Kevin's test case can't see it in a query prior to the insert means that it's definitely API24 or later test class. I'll go back to sleep!
    – Doug B
    Commented May 31, 2013 at 1:47
  • 1
    Yes, using standard PushTopic and api 27.0 Commented May 31, 2013 at 2:25

2 Answers 2


I just did some research on this and found an answer in the Salesforce developer documentation page "Isolation of Test Data from Organization Data in Unit Tests": https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_testing_data_access.htm

Under the last major bullet ("There might be some cases where you can’t create certain types of data from your test method because of specific limitations. Here are some examples of such limitations.") the 2nd to last bullet on the page explains:

"For some sObjects that have fields with unique constraints, inserting duplicate sObject records results in an error. For example, inserting CollaborationGroup sObjects with the same names results in an error because CollaborationGroup records must have unique names. This happens whether or not your test is annotated with IsTest(SeeAllData=true)."

PushTopics is in the same situation as the example given for CollaborationGroup. PushTopic names must be unique because they are used in the API to subscribe to the topic, and this impacts the re-use of names in test classes.


Based on your finding that explicitly setting the PushTopic name to be unique in the test case doesn't cause the duplicate bug I'm inclined to agree that, yes, it would appear you have found a bug in @isTest(SeeAllData=false) related to the Streaming API.

Have you raised a support case? If/when you do, please include the number here somewhere so future users can reference it if needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .