SalesForce Test Classes

I'm no expert on SalesForce, but I've been working with it for a year now, and I think I'm starting to get why things work the way they do.  One thing I figured out today was that it would sometimes be much more helpful if my test classes could fail with a descriptive message of what went wrong instead of failing on a generic assert.  The test classes I inherited from our consultants who wrote this do things like:

System.assert(result.isSuccess==true);

This is great on the surface, and we want to test this, but when the result fails, we really want to know why it failed.  To facilitate this, I came up with a new class, testException, that I can throw when I want a test to fail:

public class testException extends Exception {}

I can then make my tests fail with better information by using this exception.  For example, the System.assert example above, could be rewritten as:

if ( !result.isSuccess)
{
    throw new testException('test failed: reason is '
                            + result.reason);
}

Now, when the test fails, it will be obvious from the error why it failed, and I can include information about what led up to the failure.  (One note is that for some reason do you have to declare your own exception class.  You cannot throw new Exception().)

Admittedly, this isn't rocket science, but I thought it made a much better style for coding your tests.

UPDATE:
Did I mention that I'm still learning all this SalesForce stuff?  If it wasn't obvious, this'll help make it readily apparent. 

So I figured something out after writing this article and playing with the tests some more.  The System.assert() method actually has an additional form that allows you to do much the same thing:

System.assert(result.isSuccess==true, "operation failed: " +
                                       result.reason);

So I'm not sure if there's really any reason to define your own exception class just for unit tests.  It might be useful if you wanted to catch the exception in some case, but my test classes aren't doing that.

Attention tech support: we're not idiots!

I cut my teeth doing Tech Support.  My first real job out of high school was doing some low-level engineering and technical support.   I did this for a number of years, until I eventually got the opportunity to join the development team that was being put in place.  When I got the chance, I jumped at it.  About 6 or 7 years ago, that development team was downsized.  As a result, I joined a small team of four people whose goal was to maintain and keep alive the product that had come out of that office.  For the next 4 or so years, we maintained the product as best we could.  The other three guys each sort of took ownership of parts of the product, I pitched in where I could but the I also bore the brunt of the technical support requirements for that product.  Essentially, I became a one-man technical support department, and supported all of our customers with the exception of a few very large accounts who got one-on-one support from the other developers.

So I get the support mentality.  I understand the limitations that arise when multiple product interact, and the difficulties that arise from trying to balance your obligation to support your product while avoiding trying to troubleshoot someone else's -- or worse, having to teach your customers basic things like how to edit files.  I really do get it.  I also struggled with seemingly impossible problems that occur, but you have no idea how and no way to reproduce, and very few ideas on how to troubleshoot.  I have been there.

So, why is it that when I call technical support, they treat me like a moron.  The latest example?  Salesforce.com.  Now, don't get me wrong.  My experience with Salesforce.com over the past year has been largely trial-by-fire.  I took a training class that was enough to get my feet wet, but haven't taken the "real" developer class (yet).  Despite that, I think I'm doing pretty good and have worked out most of how the system works.  The point, I guess, is that I'm no expert, but I do know mostly what I'm doing.  So when I, out of the blue, started getting error reports from Salesforce last week that said "System.LimitException: the daily limit would be exceeded by the operation" and our Lead generation process ground to a halt, I was understandably concerned.

As an aside: that's a horrible error message.  While it does tell you what is happening, sort of, it would be SO simple to note the limit that would be exceeded.  Instead, we're left not having a clue where to look.

Salesforce.com calls itself a multitenant platform, meaning that there are many organizations hosted on a single server (or likely cluster).  I have no idea how exactly they've put the platform together, but that's basically it.  Because many organizations run on a single cluster (and, I suspect, to be able to fleece you for a bit more cash), they've implemented limits on various resources throughout the platform.  And they're generally not onerous limits.  For example, a single "request" can perform up to 150 DML (similar to SQL) queries.  If you need more than that, chances are you can refactor your code into a more efficient design that doesn't actually need that many.  By enforcing that you write efficient code, they keep the platform running smoothly for everyone.  And that is cool.

But as for daily limits, there are only a few that they document (most are, as above, per request).  Your organization is limited to 1,000 API requests per day per user.  We were nowhere near this limit.  There are limits on workflows, on e-mail messages, and on "site" usage.  But we aren't using those features.  So it's very unclear what daily limit we were exceeding.  Thus, I opened a support case, simply asking them to identify the limit for us.

We're a very small customer for Salesforce.com.  So it's not surprising that we were guaranteed a 2-day response time.  After three days, I got a call from Salesforce.com support.  They wanted to do a gotomeeting session for me to show them the problem.  I was happy to do this, although by that time, we were no longer getting the error from Salesforce, so I couldn't reproduce the problem to show them.

As a second aside: I'm not going to name names, but I think that the ability to speak the language without an accent that makes you unintelligible should be a requirement for this field.  I have nothing against other nationalities or languages.  But IMHO putting a super-thick accent on the phone to do your technical support is like hiring someone who can't smell to work your perfume counter.  All it does is frustrate your customers.

Unfortunately, the code that we wrote on the Salesforce.com platform generates demo licenses for our software.  Because there are symbols in the code like "LicenseController" and "createDemoLicense", the support person assumed that the limit we were exceeding was the number of Salesforce.com licenses our organization had.  I had to argue for 10 minutes to convince her that the "licenses" in this case had nothing to do with their licenses.  I think I finally convinced her by pointing out that Salesforce.com didn't have "daily" license limits.

So she says she is going to research the problem and get back to me, which is fine by me.  Today I get a call back again.  This time, she tries to tell me that the e-mails I got were not actual exceptions, they were only warnings that we were approaching the limits for our organization.  I somewhat lost my cool and yelled at her a bit, pointing out that the exception was a System.LimitException which aborts the code that is executing and cannot be handled.  This is no warning.

Which brings me up to where we're at now.  She is still investigating the issue, which is great.  And maybe we won't be able to find out what the limit was or why we were approaching it.  I'm ok with that, if that's truly the case.  I just wish that support people would stop treating me like I'm an idiot, because I'm not.  I can't image how people like my in-laws would deal with this sort of thing.  They wouldn't have any clue whether the support person was telling the truth or making it up as they went along.

That said, I'm not sure how to solve the problem.  I get the vague impression that we've brought this on ourselves, but the solution may be more than a single person such as myself can implement in his spare time.