I seem to end up writing more than my share of inboundEmailHandlers to process integration data that we otherwise can't get through a REST or SOAP interface. For example:

Parsing HTML emails modeled as <table>s into SObject fields
Parsing CSV attachments on inbound emails into SObject fields

While writing the parsers is straightforward, if tedious, managing the test data leaves me searching for a better solution.

Option 1 - Test Data factories in the testmethods

PRO: isolates the testmethod from the org data
CON: Requires writing the factory which can be complex, especially for all the variants of data; and a real nightmare for HTML emails

Option 2 - Brute force test data factories - long string fields that contain the inbound CSV or HTML - saved in Lists

Example:

List<String> csvTestCases = new List<String> {
      'testcase0Row0,def,ghi, ........' + '\n' + 'testCase0Row1,jkl,mno, ...' + ... ,
      'testcase0Row1,def,ghi, ........' + '\n' + 'testCase1Row1,jkl,mno, ...' + ... ,
      ... 
 }

PRO: Isolates testdata from org
PRO: No factory code to write
PRO: Can be used to adapt live datasets into test data (albeit with some editing)
CON: Lots of cut and paste to create, always missing a quote or too many quotes as you can't have strings that cross line breaks. Really hard to maintain.

Option 3 - Static Resources

Use power editors to create the test data (Excel, HTML editor, ..)
Copy paste the resulting files into static resources

Testmethod factories then read from StaticResource using SOQL, converting from base64 into string.

  for (StaticResource sr: [select id, body from StaticResource where name like 'Test%']) {
     // convert base64 data into string and inject into test
  }

PRO: Creating test data is easy; can leverage live data to build up example testsets
PRO: Factory code is simple
PRO: Isolates testdata from org; staticResources can be migrated from environments. Note that the Apex Developers Guide does not state that StaticResource is available when using @isTest but I think the doc is wrong as this testmethod passes the assert:
```
 @isTest
    private static void testFoo() {
        system.assert([select count() from staticResource] > 0);
    }
```

So - am I missing something better?

Attribution to: cropredy

Possible Suggestion/Solution #1

I definitely think that option 3 is your best best in this case, there was a reasonably recent change to the platform that actually promotes the use of storing test data in static resources because it's a common use case: check out the documentation here. I'm sure you've read that already and know it's about storing SOBject data hence your question.

I believe your test is valid and that static resources should be available in tests as they're not stored the same way as regular data; that said, if you have issues you could perhaps store a CSV for an SObject and simply use a rich text area field to store the html content.

Attribution to: Matt Lacey
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/34407

Search form

You are here

Creating libraries of non-Sobject test data

Possible Suggestion/Solution #1

My Block Status