I've read the TDTM documentation, done some web searching, and perused a bit of the code. I still have some technical questions. (I see that there are questions here with a TDTM topic, but it wasn't one of the choices in the "Add topics" section when I created this question.)
1. I've seen other questions raised here about whether the trigger handlers are processed in the same order in a test as they are normally. This appears to have something to do with how the data is loaded into the triggerHandlers variable in the test class, i.e. the fact that the handler being tested is loaded last, and therefore isn't necessarily in the Load Order. Is this the case, i.e. are there differences, and if so, why? How do we ensure we're testing the same order as will be live?
2. On a related note, the sample test code shows making a call to get the "default" records, then adding the class being tested to the local triggerHandlers variable. But, related to #1, if we have more than one additional handler in production, and they're not loaded in the test class for handler X, then we're again not testing what's actually going to run in a live environment. Shouldn't we load *all* of our handlers into the variable in a test class? (This is more theoretical for us at the moment, but I want to know how to deal with it going forward.)
3. The call to get the cached records in fact inserts the "default" TDTM records into the trigger handler table. So after the call, they're loaded in the table, and we have them in the triggerHandlers local list variable. We then load our handler being tested into that variable. But it's not in the table. I'm missing how just having it in a local variable is causing it to be called during testing.
4. The sample test class is obviously a simple one, and shows everything happening in a single method. But because I'm not clear on #3 above, I'm not clear what we can do. Is it OK to still use a testSetup method to load the test data needed by the other test methods? Does any test method that needs to do DML need to load the triggerHandlers variable?
Thanks for any help and/or pointers!
@Vince Rice Great questions and sorry for the delay. I'm always happen to see our customer orgs leveraging the TDTM framework. Taking a shot at these.
- I have observed this, though only once and it was a few years ago. We no longer insert TriggerHandler__c records in our unit tests so I'm not necessarily sure if this is even still an issue, though we do insert them for customer tests. I would say that without evidence to the contrary this is not something to worry about in your unit tests.
- The sample code is just an example. If you are using multiple custom trigger handler classes in your org, it may very well make sense to use a single test factory method that adds all of your handlers to the getDefault() collection. That's completely up to you and how you've built out your trigger framework.
- Great point here. I believe what you have to do is make the call to getCachedRecords() first. That populates the TriggerHandler__c object with the NPSP defaults. Then insert your own custom Trigger Handler records into the object. Once that is done, the next trigger operation that goes through TDTM will requery the TriggerHandler__c object - getting the defaults as well as your custom records - and then use those for all trigger operations.
- A testSetup method should be fine for creating doing the first 2 parts of step 3 above - calling getCachedRecords and then inserting your own custom records. That should populate the TriggerHandler object properly and the data will persist for all test methods in that class.
I hope these help. If you run into issues or have other questions, please feel free to respond back here and @-mention me.
