Creating libraries of non-Sobject test data

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


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:

        private static void testFoo() {
            system.assert([select count() from staticResource] > 0);

So – am I missing something better?


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.

Source : Link , Question Author : cropredy , Answer Author : Matt Lacey

Leave a Comment