What is Amoss?

Welcome to the first in a planned series of short articles on "Amoss - Apex Mock Objects, Spies and Stubs", a new Mock Object Framework for Salesforce.

Actually, whilst I've been introducing Amoss as "Mock Object Framework" - that's a bit of a misnomer.

It's better called "Configurable Test-Double Library": It provides a mechanism for building and configuring "Test Doubles" for using in Unit Tests.

What is a "Test Double" then?

Well, it's any object that you use in a test that appears to be the same as another, usually more complex, object that the system uses. It's used in order to simplify tests, and focus them on testing only the functionality that the method being tested implements.

Example

Say, for example that I want to test a method "scheduleDelivery" on the class "Order".

This method takes a list of "DeliveryProvider" objects, and asks each in turn whether it can fulfil the delivery for us, by calling "canDeliver".

Here's that method's signature:

Now, in order to test "scheduleDelivery", we might think that we need to provide a list of real DeliveryProviders, and this may be entirely possible.

However, the DeliveryProviders may be very complex:

• Maybe they call out to different SOAP and REST APIs to different real-world delivery companies. In order to test using these real objects, we may find we have to jump through a lot of hoops to set things us (like MockHttp objects).
• Maybe their behaviour is driven by data in the database, and in order to get them to work properly we need to set up a lot of data in our tests.

The point is - why should we?

Presumably the method we're testing "scheduleDelivery" knows nothing about how DeliveryProviders make the decision - and so our tests shouldn't either.

That is, we're not trying to test what the DeliveryProvider objects do, we're testing what "scheduleDelivery" does - and so our test should focus, as much as possible, on that.

So, when we test "scheduleDelivery", instead of passing it real DeliveryProviders from the application, we instead build "Test Doubles" that look like real ones, configure them to behave in a particular way and use those instead - hence "Configurable Test Doubles".

Ideally, we want to do that in as simple and transparent a way as possible.

That's what Amoss is for.

With a small amount of code we can build a replica of DeliveryProvider, whether that's a single class, the super-class of a massive hierarchy, or a simple interface.

We do that by:

• Building a "controller".
• Telling that "controller" how we want the Test Double to behave.
• Generating the "Test Double" and using it in our test.

For example, to create and configure the DeliveryProvider Test Double we might:

We can then use this deliveryProvider object, and pass it into "scheduleDelivery", knowing full well that it will return "true" for us.

More than that, our test no longer needs to worry about how the real DeliveryProvider class behaves, or what we would need to do to get it to return true. Our test becomes simpler and easier to both write and understand.

Conclusion

Using any "Mock Object Framework", or "Configurable Test Double Library" makes writing tests like this much simpler and easier, and results in tests that focus on the thing being tested. Amoss is just one of such tools.

For more information, and to download and use Amoss - take a look at the full documentation and codebase here: https://github.com/bobalicious/amoss

Full disclosure - Amoss is an Open Source project to which I am currently the sole contributor.