New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a user, I'ld like to be able to exercise all standard TDTM handlers together with my custom handlers when running tests #690

Closed
mrbelvedere opened this Issue May 5, 2014 · 9 comments

Comments

Projects
None yet
6 participants
@mrbelvedere
Member

mrbelvedere commented May 5, 2014

Currently we only create the standard TDTM records if the table is empty. This means that a user that creates a custom trigger handler won't be able to also run the default handlers in a unit test. Ideally users should be able to run both standard and custom to see if the custom ones broke something.

We should look into making TDTM_DefaultConfig.getDefaultRecords global (or some other alternative)

@force2b

This comment has been minimized.

Contributor

force2b commented May 5, 2014

A possible way of handling this to cover both NPSP and custom trigger handlers is to move the defaults into static resources (as xml or json format). That would have a few advantages:

  • Not hardcoding trigger handlers in apex
  • Client Developers could create a specially named static resource that could be referenced by the TDTM_DefaultConfig class to retrieve custom trigger handlers to recreate. They can't modify a managed static resource, so a custom one would be necessary.
  • The TDTM_DefaultConfig code would recreate the Trigger Handlers both in Unit Tests and for new/refreshed Sandboxes.
@MWCampPC

This comment has been minimized.

MWCampPC commented Dec 4, 2014

There definitely needs to be a better way.
I have 6 test classes that started to fail after a recent update to NPSP or SF.

Added SeeAllData=true (not my favorite option) and it fixed 4. I had to update contact name in one because the contact existed in our org, and one now gets 'System.LimitException: Apex heap size too large: 14783171'

Tried creating just the trigger records, but got other errors. Must be something in the custom settings.

@njjc

This comment has been minimized.

Member

njjc commented Dec 4, 2014

Hi @MWCampPC, have you implemented Test.startTest() and Test.stopTest() methods into your test that is getting a heap error to reset the limits for a portion of the code?

@MWCampPC

This comment has been minimized.

MWCampPC commented Dec 4, 2014

@njjc
I did try that. Got it down to one line that calls a create contact method
on another class. The NPSP classes(TDTM) are a black hole that I debug
without loading from source into another org, then I don’t have enough data
to cause Limit Exception.

@ceiroa

This comment has been minimized.

Member

ceiroa commented Dec 5, 2014

@MWCampPC ~ We definitely need to define the best way to do this. In the meantime however, I would suggest removing the seeAllData=true annotation, and instead creating a new test class that your code can call that inserts the default TDTM records. These are currently defined in the getDefaultRecords method of TDTM_DefaultConfig: https://github.com/SalesforceFoundation/Cumulus/blob/dev/src/classes/TDTM_DefaultConfig.cls

Later on, it's possible that we can create a global class that dynamically instantiates TDTM_DefaultConfig, in order to expose the default TDTM configuration without locking it in place.

Hope this helps.

@MWCampPC

This comment has been minimized.

MWCampPC commented Dec 5, 2014

@ceiroa I did try manually creating the TDTM records in a test class but the test still failed. I believe it is because NPSP uses custom settings for a lot of its configuration. Without some way to get the custom settings and TDTM into the tests environment, you must use the SeeAllData. I understan that this issue is looking only at the TDTM records, but I feel the discussion should include the custom settings as well.

@kbromer

This comment has been minimized.

Member

kbromer commented Dec 5, 2014

Custom settings are built automatically as needed, if required. When the NPSP goes to pull out a new settings, if its doesn't exist, a new one is created.

If you're reliant on a particular behavior in teh custom settings (say, Household Account configuration or something else), then of course you'd need to just set that manually. Opening our settings facade as a global callable method is on the backlog.

@mrbelvedere

This comment has been minimized.

Member

mrbelvedere commented Jan 23, 2015

Included in beta release version 3.32 (Beta 8) and higher

@mrbelvedere

This comment has been minimized.

Member

mrbelvedere commented Feb 3, 2015

Included in production release version 3.32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment