4

One of the things I'm trying to do in my apex tests is to check that my code is doing the right thing internally, even if it returns the right result, e.g.

  • Is it generating the right dynamic SOQL?
  • Given a specific scenario, is the right path of function call and branch followed?
  • Is the function that is caching the result of a SOQL query actually taking use of its cache for subsequent calls?
  • Does an exception happen but is caught by a try/catch block?

Because apex cannot read the Debug Log, I developed my own debug log class that the code uses to store debug information and have the tests verify it.

I am however curious to know what other people have done in the matter. Testing that output of a class or a method given a certain input is useful, but sometimes not enough.

Improve this question
3
  • Can you provide a specific code example where System asserts don't work?
    – joshbirk
    Mar 31, 2014 at 17:42
  • Sorry if my question was not clear. I'm wondering what type of tests people are using to check that their code is working internally. It's not like I have asserts that don't work, I'm trying to find new type of assertions to add besides checking that the output is correct.
    – user7094
    Mar 31, 2014 at 17:50
  • You might gain some insight into some possible answers to your question that might suit you by reading Dan Appleman's Advanced Apex Programming. In part, I think he addresses Design Patterns issues of this sort like "Building to Test" vs "Coding, then creating Unit Tests".
    – crmprogdev
    Mar 31, 2014 at 18:28

2 Answers 2

Reset to default
7

As debugging tools for Apex are truly terrible, I can see why you might want to look at internal detail when developing.

But if you couple your tests to internal detail then you are certainly adding confusion as to what the "contract" is between users of the class and the class itself, and making it harder to change your class in the future. If you are going to do that I suggest you should do it only in rare circumstances.

On your bullet point examples:

  • If you have the right number of tests that cover the main patterns that the class is meant to support and the SOQL runtime doesn't throw an exception then the dynamic SOQL is fine.
  • Again you care about the outside behaviour of the class as exercised by the tests not its internals.
  • The Limits class can be used to check if more SOQL calls than you expect are being consumed.
  • If you have a lot of try/catch blocks then the first thing to do is get rid of them as they usually do more harm than good. Again you care about the outside behaviour of the class as exercised by the tests not its internals.

Your need to probe the internals of your classes might suggest that rather than your system being composed of many simple classes that each do one thing well, the code has got put into a few large classes whose behaviour it is hard to tie down. (Controllers in particular I struggle with.)

So my bottom line is to suggest you treat your classes more as "black boxes", and if they are hard to write "black box" tests for, think about refactoring. But not easy I know.

Improve this answer
0
6

You have a couple of options:

  1. You could make the items you wish to test into class level properties. This would allow you to access these variables in your test.
  2. You could just put assertions in your code, such that if it is not right, it throws an exception.
Improve this answer
1
  • Good thinking about assertions in my code, I don't do that nearly enough.
    – user7094
    Mar 31, 2014 at 17:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .