Trapdoor In The Sun

Alan Shanahan, Technician & Consultant


1 Comment

Force.com Apex Test Assertions: It Must Be a Real Test

In the course of building automated tests, it’s always good practice to pepper your test code with Assert statements to ensure your code is functioning as you would expect throughout. But, as I’ve seen more than one example of the specific behaviour in the first code section below, I think it’s something I should point out.

On first glance, it looks like the assertion is doing the right thing. But if you think about it, it’s not a real test. It only tests that the in-memory variable testAcc.Name has the value originally assigned to it a couple of lines back.

// Example 1. An in-memory-based test
Account testAcc = new Account();
testAcc.Name = 'Testing 123';
insert testAcc;

System.assertEquals('Testing123',testAcc.Name);

What it really needs to do, so that it becomes a “real” test is for the test method to query the database record just inserted and to retrieve the Name value from the record, then check it against the expected value, as shown below.

// Example 2. A database-based test
Account testAcc = new Account();
testAcc.Name = 'Testing 123';
insert testAcc;

Account checkAcc = [SELECT Name FROM Account WHERE Id = :testAcc.Id];
System.assertEquals(checkAcc.Name,testAcc.Name);

This example is, perhaps, not a great real-world scenario but I feel it illustrates the problem well.

Happy coding, if it’s your thing.


Leave a comment

What Does OOTB Mean?

Some advice along the lines of Caveat Emptor.

You’ll all have heard the words “Out Of The Box” used. This is a well-trodden phrase in the software world; a phrase meant to indicate the suitability of a product with no customisation and little or no configuration. It seems to have replaced the “as standard” stock descriptor of old.

But when you’re in the market for a software product (or suite thereof) be careful that you don’t absorb this catchphrase without due consideration to its meaning. Like so many words and phrases in our language, the context is all-important. Some examples:

Context 1: “our product manages employee data out of the box” – non-specific
Context 2: “out of the box, this product provides the ability to record employee status values A, B, C, D, E and F” – specific

In the first example, a blanket, non-specific, statement is made. It needs further examination. Be dogged in pursuit of detail. In the second example, no extraordinary claims have been made. You can still pursue some more detail to understand it a little better.

What needs to happen is a proper comparison between precisely what you need against what the precise product capabilities are. Otherwise known as a product gap analysis. In other words it’s what you need from a product compared to what that product can do.

If you ask “can your product integrate with SuperSoftware” and the answer contains the phrase “out of the box” (perhaps with a “yes” thrown in) then you need to (a) be a little wary that salesmanship is in play and (b) ask some more searching questions. What exactly do you mean by “integrate”? What SuperSoftware products are you referring to? What do you need/expect the product to do? It’s simply too general.

That’s my point made. Let’s be careful out there.