5

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?

1 Answer 1

3

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.

2
  • 1
    thanks LaceySnr - and yep, I knew about the doc ref above - great for sobjects; not for non-sobjects. I recently switched to option3 for HTML emails and it works well - I probably saved dozens of edit-compile loops from options 1 and 2 (which i have used in the past). I'll hold this answer open for a bit to see if someone else has a super clever idea I haven't thought of. As for the doc error, I've sent in the necessary feedback form.
    – cropredy
    May 6, 2014 at 17:44
  • Yeah I'm interested in finding out if there's anything better. The only other thing I can think of (not very clean) is to use VF pages to store the HTML, then grab the body of the page in apex.
    – Matt Lacey
    May 7, 2014 at 2:46

You must log in to answer this question.

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