0

So I'm currently restructuring our Unit Test framework/pattern because it needs it and because I'm trying to track down an issue and at this point I've broken it down as simply as I can and still can't figure out the issue. This may seem small at first but I think it will lead me to the real problem.

The Problem:

I have 2 unit tests, I discovered that they run in alphabetical order no mater the order I arrange them. The first does an INSERT on a List<Account> and the second one will eventually run an UPDATE on those accounts. But for now I simply just want to debug that the second unit 2 is firing, something like:

@isTest public static void bulkUpdateAccounts() {
    System.debug('I made it!');
}

IF I change the function name to be in alphabetical priority it runs first and I can see in the debug log both test ran. BUT if it runs second, then it never runs. Why is that? Well because there is an INSERT at the end of the first test, If I remove the INSERT but keep everything else the same then I get the results I expect (both test run).

Naturally I went to Setup > Customize > Accounts > Triggers to get an idea of anything that is triggering the account. I removed all custom triggers included the TriggerHandler framework from Kevin O'Hara, as well as any packages that were installed and now there is nothing on this page. So as far as I know thing outside standard SalesForce should be effecting an Account INSERT.

With that said does anyone have any other suggestions or insights that could help me with this? I'm running out of possibilities to test. Also this issue is the same cause with testing in production which I believe is preventing deployment since I can't get over 75% because something is stopping after an INSERT

Xtremefaith
  • 4,560
  • 5
  • 39
  • 90
  • Your unit tests need to be designed to run wholly independent of one another. If you're testing the behavior of an insert in a test method, create the data, perform an insert and then assert the expected results. If you're testing the behavior of an update, you're going to first need to perform an insert of some data then perform an update on that data, and then assert the results of proper update behavior. – Mark Pond Apr 02 '15 at 01:46
  • 1
    Are you sure that's the problem? Debug logs have a maximum size, and so can be truncated. I would trust code coverage more than logs in this case. I'd wager that the debug logs are simply getting too long and some "fluff" in the middle is omitted. – sfdcfox Apr 02 '15 at 02:08
  • If you add a failing assert instead of debug output the test running framework will always report that. – Keith C Apr 02 '15 at 07:54

1 Answers1

1

Per sfdcfox's comment I was able to verify that the issue IS because I'm hitting the 2MB debug log limit. This can be see by going to Setup > Monitoring > Debug Logs

enter image description here

SOLUTION:

The now problem is slimming down the debug log and for suggestions on how to do that, refer to this post: Need to get logfile smaller

Community
  • 1
Xtremefaith
  • 4,560
  • 5
  • 39
  • 90