6

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. – Daniel Ballinger May 30 '13 at 21:36
  • Yeah, I did just that. No duplicate. I'm 99% sure this is a bug. – Kevin O'Hara May 31 '13 at 1:16
  • @DougB, this will be the standard PushTopic object rather than a custom object. – Daniel Ballinger May 31 '13 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 May 31 '13 at 1:47
  • 1
    Yes, using standard PushTopic and api 27.0 – Kevin O'Hara May 31 '13 at 2:25
8

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.

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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