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?

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.

| improve this answer | |
  • 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 '14 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 '14 at 2:46

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.